CVS difference for ai05s/ai05-0151-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file 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
 !priority High
 !difficulty Hard
+!subject Limited with and access types
-Make incomplete views more useful by allowing more use of incomplete
-access types.
+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
-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