CVS difference for ai05s/ai05-0149-1.txt
--- ai05s/ai05-0149-1.txt 2009/06/02 06:22:37 1.4
+++ ai05s/ai05-0149-1.txt 2009/06/08 03:46:17 1.5
@@ -1,13 +1,13 @@
-!standard 4.5.2(3/2) 09-05-19 AI05-0149-1/03
-!standard 4.5.2(30.2/2)
-!standard 3.10.1(2/2)
+!standard 4.5.2(30.2/2) 09-06-06 AI05-0149-1/04
+!standard 8.6(24)
!standard 8.6(25/2)
+!standard 8.6(27/2)
!class Amendment 09-04-12
!status work item 09-04-12
!status received 09-04-12
!priority Medium
!difficulty Medium
-!subject Access types and conversion, membership, and limited with
+!subject Access types conversion and membership
!summary
@@ -21,20 +21,15 @@
conversion to check if the conversion will succeed, but the current
rules for access-type membership tests don't allow for this.
-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.
+If an access type is made visible via a limited with, it can't be used
+in the client package to declare variables or components, since it is an
+incomplete type. (Note that in AI05-0151 we dicuss the possibility of using
+incomplete types for parameters and results.) In this case, 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.
Finally, there seems no reason to require an explicit conversion
to a named access-to-classwide type that is certain to succeed the
@@ -44,16 +39,12 @@
!proposal
-This AI makes four related proposals:
+This AI makes three related proposals:
1) When the tested type of a membership test is a general access
type, allow the expression to be of an anonymous access type.
-2) Incomplete access types, which are access types declared in a
- limited view of a package, may be used as formal parameter and result
- types.
-
-3) Implicit conversion is provided from an anonymous access type
+2) Implicit conversion is provided from an anonymous access type
with a static accessibility level to a named, general access type,
provided the explicit conversion is legal (i.e. static accessibility
check passes; designated types match if untagged); further, if the
@@ -61,42 +52,13 @@
access type shall be covered by the designated type of the named
access type (explicit conversion allows for more possibilities).
-4) Implicit conversion is provided from a named access type with a static
+3) Implicit conversion is provided from a named access type with a static
accessibility level to a named, general access-to-classwide type,
provided the designated type of the target access type covers that of
the source type. The usual static accessibility level check applies.
-
-*Incomplete access types* are 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.
-
-
!wording
-Wording for parts (2), (3), and (4) is TBD. For part (1):
-
-Modify 4.5.2(3/2) as follows:
-
- The tested type of a membership test is the type of the range or the
- type determined by the subtype_mark. If the tested type is tagged,
- then the simple_expression shall resolve to be of a type that is
- convertible (see 4.6) to the tested type; [if untagged] {if the
- tested type is a general access-to-object type, then the
- simple_expession shall resolve to be of the same type, or
- universal_access, or an anonymous access-to-object type whose
- designated type is the same as that of the tested type, or if tagged,
- convertible to the designated type of the tested type; otherwise},
- the expected type for the simple_expression is the tested type.
-
Add after 4.5.2(30.2/2):
* if the tested type is a general access-to-object type, the type of the
@@ -106,81 +68,98 @@
non-null, the tag of the object designated by the value of the
simple_expression is covered by the designated type of the tested type.
+Revise 8.6(22-25.1) as follows:
+
+ * If the expected type for a construct is a specific type T, then the
+ type of the construct shall resolve either to T, or:
+
+ * to T'Class; or
+
+ * to a universal type that covers T; or
+
+ {* when T is a [Redundant: (named or anonymous)] general access-to-object
+ type (see 3.10) with designated type D'Class, to an access-to-object
+ type whose designated type is covered by D'Class; or}
+ [NOTE to ARG: this is relevant to parts (1) & (3)]
+
+ * when T is a specific anonymous access-to-object type (see 3.10)
+ with designated type {a specific type} D, to an access-to-object
+ type whose designated type is {D or} D'Class [or is covered by D]; or
+ {AARM Ramification: D'Class will only be legal as part of a call on a
+ dispatching operation; see 3.9.2(9), "Dispatching Operations of Tagged
+ Types". Note that that rule is not a Name Resolution Rule. }
+
+ {* when T is a named general access-to-object type (see 3.10) with
+ designated type a specific type D, to an anonymous access-to-object
+ type whose designated type is also D; or}
+ [NOTE to ARG: this is relevant to parts (1) & (2)]
+
+ * when T is an anonymous access-to-subprogram type (see 3.10),
+ to an access-to-subprogram type whose designated profile is
+ type-conformant with that of T.
+
+Add after 8.6(27):
+
+ Other than for the simple_expression of a membership test, if the
+ expected type for a name or expression is not the same as the actual
+ type of the name or expression, the actual type shall be convertible
+ to the expected type (see 4.6); further, if the expected type is a
+ named access-to-object type and the actual type is an anonymous
+ access-to-object type, then the name or expression shall denote a view
+ with an accessibility level for which the statically deeper
+ relationship applies [Redundant: ; in particular it shall not denote
+ an access parameter nor a standalone access object].
+ {AARM NOTE: This is to minimize cases of implicit conversions when
+ the accessibility check cannot be performed at compile-time. We word
+ this this way because access discriminants should also be disallowed
+ if their enclosing object is designated by an access parameter.}
+
!discussion
-We have grouped part (1) with these other proposals as any
-changes to the implicit conversion rules will affect the name
-resolution rules for membership. Hence, we anticipate the wording
-proposed above for (1) to be refined further when we finalize the
-wording for (3) and (4), and hence having separate AIs will just
-create integration headaches.
+We have grouped part (1) with these other proposals as any changes to
+the implicit conversion rules will affect the name resolution rules for
+membership.
The basic goal of (1) is that membership will return false if an attempt
-to convert the simple_expression into the tested type will be
-illegal or fail a run-time check.
+to convert the simple_expression into the tested type will be illegal or
+fail a run-time check.
-We started from the approach used for tagged types, by allowing
-the simple_expression to be of any type that is convertible to the
-tested type. We then relaxed that to simplify name resolution,
-since we don't normally worry about things like static designated subtype
-matching in name resolution. We morphed the requirement for
-convertibility into a criteria for membership returning True.
+We started from the approach used for tagged types, by allowing the
+simple_expression to be of any type that is convertible to the tested
+type. We then relaxed that to simplify name resolution, since we don't
+normally worry about things like static designated subtype matching in
+name resolution. We morphed the requirement for convertibility into a
+criteria for membership returning True.
We considered making a membership test illegal rather than returning
-False if the corresponding conversion would be illegal, but that
-didn't seem as friendly in places like generics, and there are
-currently no legality rules associated with membership tests.
-
-We have limited it to access-to-object types, as there
-seems little need for the corresponding capability for
-access-to-subprogram types.
+False if the corresponding conversion would be illegal, but that didn't
+seem as friendly in places like generics, and there are currently no
+legality rules associated with membership tests.
+We have limited it to access-to-object types, as there seems little need
+for the corresponding capability for access-to-subprogram types.
+
There are some places where run-time accessibility checks are performed
other than conversions to a named type, and we aren't helping for those.
But this seems like a simple improvement that handles many of the
interesting cases of run-time accessibility checks.
-
-Proposal part (2) 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 third part of this proposal addresses the implicit conversion of
+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.
+parameters. For parameters, AI05-0151 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.
-The fourth part of this proposal provides the same level of implicit
+The third part of this proposal provides the same level of implicit
conversion for access-to-classwide types as is provided for classwide
-types directly. This part has more upward compatilibity issues, so
+types directly. This part has more upward compatibility issues, so
will require additional evaluation.
-IMPLEMENTATION CONCERNS:
+SAFETY CONCERNS:
-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
@@ -192,65 +171,58 @@
appropriate here.
COMPATIBILITY CONCERNS:
+
+Introducing additional implicit conversions *from* anonymous access
+types and/or *to* named access-to-classwide types could introduce some
+ambiguity into existing programs. For the conversions *from* an
+anonymous access type, this seems like a relatively small price to pay,
+as the ambiguity would occur under limited 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.
+
+For the conversion *to* a named access-to-classwide type, this is
+perhaps more of a concern, as currently two subprograms that differ in
+the named access type of a parameter are not ambiguous unless the actual
+is "null" or an allocator. The extent of this ambiguity should be
+investigated if possible in existing archives of customer code. Note
+that this applies to some extent to both proposals (2) and (3), though
+more so to (3), as existing code could never pass an anonymous access
+type to a formal that is of a named access type.
-Introducing additional implicit conversions *from* anonymous access types
-and/or *to* named access-to-classwide types could introduce some
-ambiguity into existing programs. For the conversions *from* an anonymous
-access type, this seems like a relatively small
-price to pay, as the ambiguity would occur under limited 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.
-
-For the conversion *to* a named access-to-classwide type, this is perhaps
-more of a concern, as currently two subprograms that differ in the named
-access type of a parameter are not ambiguous unless the actual is "null"
-or an allocator. The extent of this ambiguity should be investigated
-if possible in existing archives of customer code. Note that this applies
-to some extent to both proposals (3) and (4), though more so to (4), as
-existing code could never pass an anonymous access type to a formal
-that is of a named access type.
-
-QUESTIONS:
-
-Q: Might a special "type T is access;" syntax be worthwhile? 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.
-
-We have not proposed this syntax for now, as the need does not seem compelling.
-However, it could be added to this proposal, now or at a later date.
-
-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 for the latter, since in 90%
-of the cases nothing special would be required, and in the
-few cases where something special is required, the implementation
-can always create a wrapper.
!example
+ type Acc is access T;
+ type Class_Acc is access T'Class;
+
+ procedure P(X : access T) is
+ Y : Acc;
+ Z : Class_Acc;
+ begin
+ Y := X; -- Illegal implicit conversion, since X is an access parameter.
+ Y := Acc(X); -- Legal, might raise Program_Error
+
+ if X in Acc then
+ Y := Acc(X); -- Known to be safe now
+ else
+ Y := null;
+ end if;
+
+ Z := Y; -- Legal implicit conversion
+
+ Y := Z; -- Illegal implicit conversion
+ end P;
!ACATS test
-ACATS C-Tests are needed to check that this membership is allowed and
-gets appropriate results.
+ACATS C-Tests are needed to check that this membership and these implicit
+conversions are allowed and (in the case of the membership) get appropriate
+results. A B-test is also needed for the legality rule.
!appendix
Questions? Ask the ACAA Technical Agent