Version 1.2 of ais/ai-00004.txt

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

!standard E.2.2 (09) 99-07-07 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
!subject Conversions to types derived from remote access types

!summary

!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)

Replace the paragraph:

An access type declared in the visible part of a remote types or remote call interface library unit is called a remote access type. Such a type shall be either an access-to-subprogram type or a general access type that designates a class-wide limited private type.

by:

!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).


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

Questions? Ask the ACAA Technical Agent