Version 1.1.1.1 of ais/ai-00004.txt

Unformatted version of ais/ai-00004.txt version 1.1.1.1
Other versions for file ais/ai-00004.txt

!standard E.2.2 (09)          96-11-16 AI95-00004/05
!class binding interpretation 95-06-25
!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
!subject Conversions to types derived from remote access types
!summary 96-09-15
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 96-09-15
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 96-09-15
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 95-06-25
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 96-09-15
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.
!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).


****************************************************************

Questions? Ask the ACAA Technical Agent