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

--- ai05s/ai05-0149-1.txt	2009/12/18 07:16:16	1.8
+++ ai05s/ai05-0149-1.txt	2010/06/08 05:59:05	1.9
@@ -1,4 +1,4 @@
-!standard 4.5.2(30.2/2)                               09-12-17  AI05-0149-1/06
+!standard 4.5.2(30.2/2)                               10-06-08  AI05-0149-1/07
 !standard 8.6(25/2)
 !standard 8.6(27/2)
 !standard 8.6(29)
@@ -9,11 +9,13 @@
 !status received 09-04-12
 !priority Medium
 !difficulty Medium
-!subject Access types conversion and membership
+!subject Access type conversion and membership
 
 !summary
 
-(See proposal.)
+Values of anonymous access types can now be implicitly converted to named
+access types when the conversion has to be safe. Moreover, anonymous access types
+are now allowed as the type of the expression of a membership test.
 
 !problem
 
@@ -104,28 +106,22 @@
   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 the tag check or the accessibility check might fail. We word
-     this this way because access discriminants should also be disallowed
+     the tag check or the accessibility check might fail. We word
+     it 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:
+Add a new paragraph after 8.6(29):
 
-  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
+  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
+  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.}
+      to compare anonymous access values.
 
 !discussion
 
@@ -139,10 +135,10 @@
 
 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
+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.
+name resolution. We morphed the requirement for convertibility into a
+criterion 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
@@ -172,11 +168,11 @@
 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.
+conversions, which might fail a tag check. For example, if we have
+"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.
 
 COMPATIBILITY CONCERNS:
 
@@ -234,14 +230,17 @@
 A preference rule to T1."=" would introduce Beaujolais effects. That's bad.
 A preference rule to Standard."=" 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.
+would make "=" essentially unusable, which is bad, incompatible, and stupid.
+So further expansion of implicit conversion is not possible.
 
 
 !example
 
     type Acc is access T;
     type Class_Acc is access T'Class;
+    type Rec is record
+       Comp : access T'Class;
+    end record;
 
     procedure P(X : access T) is
         Y : Acc;
@@ -255,10 +254,11 @@
         else
             Y := null;
         end if;
+        Rec.Comp := Y; -- Implicit conversion legal in Ada 2005 and Ada 2012.
 
-        Z := Y;  -- Legal implicit conversion
+        Z := Rec.Comp; -- Implicit conversion legal in Ada 2012, but not in Ada 2005.
 
-        Y := Z;  -- Illegal implicit conversion
+        Y := Rec.Comp; -- Illegal implicit conversion (T does not cover T'Class).
     end P;
 
 !corrigendum 4.5.2(30.2/2)