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

Differences between 1.6 and version 1.7
Log of other versions for file 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