CVS difference for ai05s/ai05-0149-1.txt
--- ai05s/ai05-0149-1.txt 2009/07/11 03:06:22 1.6
+++ ai05s/ai05-0149-1.txt 2009/11/04 01:44:07 1.7
@@ -1,4 +1,4 @@
-!standard 4.5.2(30.2/2) 09-06-06 AI05-0149-1/04
+!standard 4.5.2(30.2/2) 09-11-03 AI05-0149-1/05
!standard 8.6(24)
!standard 8.6(25/2)
!standard 8.6(27/2)
@@ -33,13 +33,13 @@
Finally, there seems no reason to require an explicit conversion
to a named access-to-classwide type that is certain to succeed the
-tag check (i.e., is a "widening" conversion). This will reduce
+tag check (i.e., is a "widening" conversion). This would reduce
the need for anonymous access types in general, which is considered
probably a good thing.
!proposal
-This AI makes three related proposals:
+This AI makes two 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.
@@ -51,12 +51,7 @@
designated type is tagged, the designated type of the anonymous
access type shall be covered by the designated type of the named
access type (explicit conversion allows for more possibilities).
-
-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.
-
+
!wording
Add after 4.5.2(30.2/2):
@@ -73,28 +68,23 @@
* 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 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)]
+ - to a universal type that covers T; or
- * 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
+ - when T is a specific anonymous access-to-object type (see 3.10)
+ with designated type D, to an access-to-object type whose
+ designated type is 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. }
+ Types". Note that this 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 a named general access-to-object type (see 3.10) with
+ designated type D, to an anonymous access-to-object
+ type whose designated type is covered by D; or}
+ [NOTE to ARG: this is relevant to both parts (1) & (2)]
- * when T is an anonymous access-to-subprogram type (see 3.10),
+ - 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.
@@ -114,9 +104,28 @@
this this way because access discriminants should also be disallowed
if their enclosing object is designated by an access parameter.}
+Modify 8.6(29) by adding a preference rule for universal_access equality:
+
+ There is a preference for the primitive operators (and ranges) of the
+ root numeric types root_integer and root_real. In particular, if two
+ acceptable interpretations of a constituent of a complete context
+ differ only in that one is for a primitive operator (or range) of the
+ type root_integer or root_real, and the other is not, the
+ interpretation using the primitive operator (or range) of the root
+ numeric type is preferred. {Similarly, there is a preference for the
+ equality operators of the universal_access type (see 4.5.2). If two
+ acceptable interpretations of a constituent of a complete context
+ differ only in that one is for an equality operator of the
+ universal_access type, and the other is not, the interpretation using
+ the equality operator of the universal_access type is preferred.}
+ {AARM NOTE: This is necessary because of implicit conversion
+ from an anonymous access type to a named access type, which would
+ allow the equality operator of any named access type to be used
+ to compare anonymous access values.}
+
!discussion
-We have grouped part (1) with these other proposals as any changes to
+We have grouped part (1) with proposal (2) as any changes to
the implicit conversion rules will affect the name resolution rules for
membership.
@@ -146,40 +155,35 @@
The second part of this proposal addresses the implicit conversion of
anonymous access types to named access types for everything *but*
-parameters. For parameters, AI05-0151 allows the original (incomplete)
+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 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 compatibility issues, so
-will require additional evaluation.
-
SAFETY CONCERNS:
For implicit conversion, we are only allowing it when the accessibility
-check is known to succeed statically. Since an explicit conversion is
+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
+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
+that it will fail the tag check. Again, an explicit conversion is more
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
+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
+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.
@@ -188,12 +192,47 @@
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.
+investigated if possible in existing archives of customer code. Note
+that this applies to some extent to both proposals (2) and the rejected
+proposal (3) (see below), 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.
+
+Note that we have added a preference rule for the equality operators
+of universal_access, so that we don't end up with massive ambiguity
+when comparing two anonymous access values, since they are now implicitly
+convertible to all sorts of named access types, each of which presumably
+has its own equality operators.
+
+THE REJECTED THIRD PART OF THE PROPOSAL:
+
+We rejected the following further expansion of implicit conversion:
+
+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.
+
+This third part of this proposal provided the same level of implicit
+conversion for access-to-classwide types as is provided for classwide
+types directly. This part had more upward compatibility issues, and
+was ultimately rejected for that reason, as well as difficulties
+resolving "=" between implicitly convertible named types.
+
+The latter problem is illustrated by:
+
+ type T1 is access all D'Class;
+ type T2 is access all D'Class;
+ A, B : T1 := ...;
+ A_eq_B : Boolean := A = B; -- Ambigious (T1."=", T2."=", Standard."=")
+
+A preference rule would introduce Beaujolais effects or would cause any
+user-defined "=" operators to be ignored. That's both bad and
+incompatible; not trying to fix the problem would make "=" essentially
+unusable. So further expansion of implicit conversion is not possible.
+
+
!example
type Acc is access T;
@@ -1140,6 +1179,48 @@
could reconcile these two AIs?? (It seems that we need the legality rule even if
we don't do this Amendment, because we already have a hole in the language. It's
a bit uncomfortable to use an Amendment to fix a place where the language is broken...)
+
+****************************************************************
+
+From the minutes of the Brest ARG meeting:
+
+Steve writes an example:
+
+ type T1 is access all D'Class;
+ type T2 is access all D'Class;
+
+ A, B : T1 := ...;
+
+ A_eq_B : Boolean := A = B; -- Ambigious (T1."=", T2."=", Standard."=")
+
+Randy notes that this seems to happen for anonymous access as well (if there is an
+appropriate named type around):
+
+ X, Y : access D;
+ type T3 is access all D;
+
+ X_eq_Y : Boolean := X = Y; -- Ambigious (T3."=", Standard."=")
+
+We can have a preference rule to use Standard."=" in the latter case (both anonymous
+access), but the named to named comparison is unfixable without introducing a Beujoulais
+effect (we can only have preference rules for things that are always visible (that is,
+entities in Standard)). (A preference for Standard."=" over the user-defined "=" for a
+specific type would work semantically, but would be very surprising and incompatible –
+effectively, user-defined "=" would be ignored.) So you can't call "=" at all if there
+is more than one type. That's not going to work. We quickly lose interest in proposal 3.
+
+A preference rule to avoid ambiguity with "=" will have to be crafted for proposal 2.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 3, 2009 12:46 PM
+
+Here is an update to AI-149. The third part of the proposal is dropped, which
+means we can eliminate many of the wording changes. I also added a preference
+rule for universal_access equality operators, as directed.
+
+[This is version /05 of the AI - ED]
****************************************************************
Questions? Ask the ACAA Technical Agent