!standard E.2.2 (09) 99-08-31 AI95-00004/06 !class binding interpretation 95-06-25 !status Corrigendum 2000 99-05-24 !status WG9 approved 96-12-07 !status ARG approved 12-0-0 96-10-07 !status ARG approved (subj. ed. rev., letter ballot was 12-0-0) 96-10-03 !status ARG approved 7-0-1 (subject to letter ballot) 96-06-17 !status work item 95-06-25 !status received 95-06-25 !reference AI95-00062 !priority Medium !difficulty Medium !qualifier Omission !subject Conversions to types derived from remote access types !summary Notwithstanding the rule in 3.10(7), a remote access type (unlike other access types) has no associated storage pool. If a type is derived from a remote access type, then the derived type is also a remote access type. !question NOTE 3.4(31) says, "If the parent type is an access type, then the parent and the derived type share the same storage pool...". E.2.2(17) says: The Storage_Pool and Storage_Size attributes are not defined for remote access-to-class-wide types; the expected type for an allocator shall not be a remote access-to-class-wide type; a remote access-to-class-wide type shall not be an actual parameter for a generic formal access type; This seems to imply that a remote access type has no storage pool, which is confirmed by AARM-E.2.2(17.a): 17.a Reason: All three of these restrictions are because there is no storage pool associated with a remote access-to-class-wide type. However, E.2.2(17) allows allocators for types derived from remote access types. How can an allocator work for a type that has no storage pool? !recommendation Notwithstanding the rule in 3.10(7), a remote access type (unlike other access types) has no associated storage pool. If a type is derived from a remote access type, then the derived type is also a remote access type, and hence also has no associated storage pool. Thus, type conversions are allowed between such types (see E.2.2(11,15)). The restrictions in E.2.2(10-17) apply to types derived from remote access types. !wording Add "A type that is derived from a remote access type is also a remote access type." at the end of E.2.2(9). !discussion Normally, a derived access type has the same storage pool as its parent. See AI95-00062, which confirms NOTE 3.4(31). However, the intent of E.2.2(17) is that a remote access type has no storage pool. Therefore, a type derived from a remote access type cannot have a storage pool, either. Querying 'Storage_Pool and 'Storage_Size should be illegal by E.2.2(17). Similarly, allocators should be illegal. !corrigendum E.02.02(9) @drepl An access type declared in the visible part of a remote types or remote call interface library unit is called a @i. Such a type shall be either an access-to-subprogram type or a general access type that designates a class-wide limited private type. @dby An access type declared in the visible part of a remote types or remote call interface library unit is called a @i. Such a type shall be either an access-to-subprogram type or a general access type that designates a class-wide limited private type. A type that is derived from a remote access type is also a remote access type. !ACATS test Test(s) are needed. The restrictions for a (derived) remote access type should be tested with a B-Test, possibly as added test cases in BXE2011. In addition, a C-Test ought to check that these behave as remote access types. !appendix !section E.2.2(09) !section E.2.2(12) !subject Conversions to types derived from remote access types !reference RM9X-E.2.2(9);5.95 !reference RM9X-E.2.2(12);5.95 !from Norman Cohen !reference as: 94-5035.g Norman H. Cohen 94-12-19>> !discussion Wasn't the intent to allow conversion from remote access types to DESCENDANTS of conformant remote access types? After all, derivation should be expected to preserve the knowledge that a special remote-access-type representation is required. **************************************************************** !section E.2.2(09) !section E.2.2(12) !subject Conversions to types derived from remote access types !reference RM9X-E.2.2(9);5.95 !reference RM9X-E.2.2(12);5.95 !reference 94-5035.g Norman H. Cohen 94-12-19 !from Bob Duff !reference as: 94-5037.g Bob Duff 94-12-19>> !discussion > Wasn't the intent to allow conversion from remote access types to > DESCENDANTS of conformant remote access types? After all, derivation > should be expected to preserve the knowledge that a special > remote-access-type representation is required. I'm not sure what the "intent" was, but as I read it, such a conversion would be illegal. **************************************************************** !section E.2.2(09) !section E.2.2(12) !subject Conversions to types derived from remote access types !reference RM9X-E.2.2(9);5.95 !reference RM9X-E.2.2(12);5.95 !reference 94-5035.g Norman H. Cohen 94-12-19 !reference 94-5037.g Bob Duff 94-12-19 !from Anthony Gargaro 95-01-08 !reference as: 95-5060.b Anthony Gargaro 95-1-8>> !discussion >> Wasn't the intent to allow conversion from remote access types to >> DESCENDANTS of conformant remote access types? After all, derivation >> should be expected to preserve the knowledge that a special >> remote-access-type representation is required. > I'm not sure what the "intent" was, but as I read it, such a conversion > would be illegal. The remote property for a type is a consequence of where the type is declared; i.e., in the visible part of a remote types or remote call interface package. Thus, if the descendant is declared in such a visible part the conversion is allowed; otherwise the conversion is illegal since the descendant is not a remote access type. However, this does raise an issue of how to reconcile 3.4 (31) and E.2.2 (14). ****************************************************************