Version 1.1 of ai05s/ai05-0151-1.txt

Unformatted version of ai05s/ai05-0151-1.txt version 1.1
Other versions for file ai05s/ai05-0151-1.txt

!standard 3.10.1(2/2)          09-04-29 AI05-0151-1/01
!class Amendment 09-04-29
!status work item 09-04-29
!status received 09-04-29
!priority High
!difficulty Hard
Make incomplete views more useful by allowing more use of incomplete access types.
The limited with clause makes incomplete views of types visible. Tagged incomplete types are useful for formal parameters, but most other incomplete types are pretty much useless, except as the designated type of an access type. It would be nice if a named access type declared in a package named in a limited with clause could be used somehow, if only as a parameter type.
If the named (incomplete) access type cannot be used directly, then it might be natural to use anonymous access types in the client package. However, these anonymous access types then need to be converted to the named access type at some point, and that currently requires an explicit conversion. It would be preferable if safe conversions from an anonymous access type to a named access type were implicit.
This AI makes two related proposals:
1) Incomplete access types may be used as formal parameter and result types.
2) Implicit conversion is provided from an anonymous access type
with a static accessibility level to a named access type, provided the level of the anonymous access type is no deeper than that of the named access type; further, if the designated type is tagged, the designated type of the anonymous access type shall be covered by the designated type of the named access type.
An incomplete access type may be introduced explicitly using the following syntax:
type T is access;
Incomplete access types are also created as part of a limited view of a package. Each non-derived access type declared in the visible part of a package spec becomes an incomplete access type in the limited view. Derived access types don't become incomplete access types in the limited view because they aren't syntactically distinguishable from any other kind of untagged derived type.
Incomplete named access types may not be used for components. Instead, anonymous access types may be used for those, and then the anonymous access type may be implicitly converted to the named access type in places with a full view of the named access type.
** TBD **
This proposal addresses a concern that a "limited with" naming a package with named access types forces the use of a lot of explicit conversion and/or anonymous access types in the clients.
We are proposing to allow "incomplete access types" (not to be confused with "incomplete types whose full type is an access type" ;-) to be used as formal parameter and result types, analogous to tagged incomplete types, as well as providing some additional implicit conversions from anonymous access types to named access types.
The second part of this proposal addresses the implicit conversion of anonymous access types to named access types for everything but parameters. For parameters, the first part of this proposal allows the original (incomplete) named access type to be used as a formal parameter type in the client package, rather than having to resort to an anonymous access type. Using anonymous access types for formal parameters introduces additional dynamic accessibility checks, whereas using the named access type directly avoids that.
An incomplete access type is OK as a parameter or result since access-type parameters and results are always passed by copy, and the implementation can use a default general-access-type representation for them, even if the full named access type turns out to have some kind of aspect clause. This is in contrast to the case with components, where an aspect clause would need to be obeyed to ensure streaming, aliased objects, etc., work as expected.
Note that we have chosen to allow incomplete access types as function results, even though we restricted tagged incomplete types to being parameters. Tagged incomplete type results introduces a number of tricky issues that are not present for incomplete access types, so there seems no reason to restrict incomplete access types from being result types.
For implicit conversion, we are only allowing it when the accessibility check is known to succeed statically. Since an explicit conversion is always available, there seems no reason to hide conversions that might in fact fail. Similarly, we are disallowing implicit "narrowing" conversions, which might fail a tag check. For example, if "type NT is new T with ..." we are disallowing an implicit conversion from anon acc-to-T'class to a named acc-to-NT'class, since there is a possibility that it will fail the tag check. Again, an explicit conversion is more appropriate here.
Introducing additional implicit conversions could introduce some ambiguity into existing programs. This seems like a relatively small price to pay, as the ambiguity would occur under unlikely circumstances: the actual parameter is of an anonymous access type, and there are two functions with the same name differing only in that one has an access parameter where the other has a parameter of a named access type. Such a pair of functions would be ambiguous if the actual parameter were of the named access type, so it doesn't seem unreasonable that they would also end up ambiguous if the actual were of an anonymous type.
Q: is the special "type T is access;" syntax worth it? Perhaps it could be a way to indicate in a limited view that a derived type is in fact an access type. E.g.:
type NT is access; type NT is new T;
and in general it would be a way to allow the incomplete type to be used as a formal parameter/result type before the full type definition is provided.
ASIDE: Hmmm... I wonder whether we could have generic formal incomplete types as a way to allow instantiation with a private type before it is fully defined. This might be sufficient for a "signature" generic. end of ASIDE.
Q: Should the calling convention of a subprogram with an incomplete access type formal be automatically intrinsic, or should we presume that implementations can deal with this issue under the covers if necessary? I'd vote the latter.
--!corrigendum 3.10.1(2/2)
!ACATS test
Add ACATS tests for this new feature.


Questions? Ask the ACAA Technical Agent