CVS difference for ai05s/ai05-0151-1.txt
--- ai05s/ai05-0151-1.txt 2009/04/30 06:18:43 1.1
+++ ai05s/ai05-0151-1.txt 2009/05/19 22:41:16 1.2
@@ -1,154 +1,27 @@
-!standard 3.10.1(2/2) 09-04-29 AI05-0151-1/01
+!standard 3.10.1(2/2) 09-05-19 AI05-0151-1/02
!class Amendment 09-04-29
+!status deleted 09-05-19
!status work item 09-04-29
!status received 09-04-29
+!subject Limited with and access types
-Make incomplete views more useful by allowing more use of incomplete
+This AI has been merged into AI05-0149-1.
-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
-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
-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.
-Add ACATS tests for this new feature.
Questions? Ask the ACAA Technical Agent