CVS difference for ais/ai-00235.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00235.txt

--- ais/ai-00235.txt	2000/06/02 00:23:26	1.3
+++ ais/ai-00235.txt	2000/06/20 04:22:45	1.4
@@ -1,4 +1,4 @@
-!standard 03.10.02  (02)                               00-05-31  AI95-00235/02
+!standard 03.10.02  (02)                               00-06-16  AI95-00235/03
 !class binding interpretation 00-05-31
 !status received 00-05-09
 !status work item 00-05-09
@@ -45,8 +45,9 @@
     For an attribute_reference with attribute_designator Access (or
     Unchecked_Access -- see 13.10), the expected type shall be
     a single access type whose designated type covers the type of
-    the prefix, or whose designated profile is type conformant
-    with that of the prefix. [The prefix of such an attribute_reference
+    the prefix, or, if the type of the prefix is D'Class, whose
+    designated type is D, or whose designated profile is type conformant with
+    that of of the prefix. [The prefix of such an attribute_reference
     is never interpreted as an implicit_dereference or parameterless
     function_call (see 4.1.4).] The designated type or profile of the
     expected type of the attribute_reference is the expected type or
@@ -111,7 +112,8 @@
 For an @fa<attribute_reference> with @fa<attribute_designator> Access (or
 Unchecked_Access -- see 13.10), the expected type shall be
 a single access type whose designated type covers the type of
-the @fa<prefix>, or whose designated profile is type conformant
+the @fa<prefix>, or, if the type of the @fa<prefix> is D'Class, whose
+designated type is D, or whose designated profile is type conformant
 with that of the @fa<prefix>. The @fa<prefix> of such an
 @fa<attribute_reference> is never interpreted as an @fa<implicit_dereference>
 or parameterless @fa<function_call> (see 4.1.4). The designated type or profile
@@ -1558,6 +1560,208 @@
 Sent: Thursday, June 01, 2000 8:30 AM
 
 Looks good to me (modulo Gary's suggestion about the example).
+
+*************************************************************
+
+From: Ed Schonberg
+Sent: Thursday, June 01, 2000 8:27 PM
+
+Randy's test now passes on gnat:
+
+nile{schonber}65: gnatmake -I../ c3a200x
+gcc -c -I../ c3a200x.adb
+gcc -c -I../ c3a200xa.adb
+gcc -c -I../ report.adb
+gnatbind -aO./ -aO../ -I- -x c3a200x.ali
+gnatlink c3a200x.ali
+nile{schonber}66: c3a200x
+
+,.,. C3A200X ACVC 2.0 00-06-01 21:15:39
+---- C3A200X Check that 'Access and 'Unchecked_Access attributes can use
+                the type of their prefix in resolving overloading..
+==== C3A200X PASSED ============================.
+
+
+This took about an hour of work, and added 50 lines to the front-end, so
+needless to say we find this a perfectly implementable rule (and furthermore
+one that will not force us to change all these overloaded prefixes in our own
+run-time!).
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 06, 2000 7:22 AM
+
+I have modified our compiler to implement AI-235:
+
+varenne$ c3a200x
+
+,.,. C3A200X ACVC 2.2 00-06-06 14:06:02
+---- C3A200X Check that 'Access and 'Unchecked_Access attributes can use
+                the type of their prefix in resolving overloading..
+==== C3A200X PASSED ============================.
+
+It took me a bit less than a day, and the version control system tells me that I
+have changed 272 lines (to be honest, these changes included fixing a bug in the
+handling of the access-to-subprogram case that I noticed while reading the
+code).  So for us this was not a big change, even though we were originally
+quite close to the RM.
+
+I haven't run an entire ACVC yet, but I am noticing that we now fail test
+b3a2016, which is not surprising since this test checks RM95 3.10.2(2).  It
+seems to me that vendors should be able to validate compilers which implement
+AI-235, and therefore that this test should be removed from the suite.  I'd like
+to hear the ACAA's opinion on this.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 16, 2000 6:21 PM
+
+Pascal said:
+
+> I haven't run an entire ACVC yet, but I am noticing that we
+> now fail test b3a2016, which is not surprising since this
+> test checks RM95 3.10.2(2).  It seems to me that vendors
+> should be able to validate compilers which implement AI-235,
+> and therefore that this test should be removed from the
+> suite.  I'd like to hear the ACAA's opinion on this.
+
+Randy responds (wearing my ACAA hat):
+
+It was obvious to me the B3A2016 would have to be changed, because as long as
+AI-235 is under consideration, testing cases that it might change (either way)
+is wrong. OTOH, the test includes some useful cases (and I had added several
+more useful cases more recently), and a B-Test is clearly needed along with a
+C-Test (assuming AI-235 passes as is). So I created a version of the test with
+all of the problematical cases commented out, and a variety of new cases.
+
+I thought it best to wait a while before issuing the test (to see if AI-235
+would be changed again), so I went on vacation rather than actually issuing it.
+But I intend to do that next week.
+
+Under the ACAA rules, this action will reset the required date, so the new test
+won't be required until January 1st, 2001. Once WG9 approves AI-235, I'll issue
+an improved version of the C-Test (at least, the name has to be changed), and a
+revised version of the new B-Test (with the commented out cases replaced,
+either as "OK" or "Error", as needed).
+
+			Randy Brukardt.
+			ACAA Technical Agent.
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Saturday, June 10, 2000 2:07 AM
+
+> !wording
+>
+> Replace 3.10.2(2) with:
+>     For an attribute_reference with attribute_designator Access (or
+>     Unchecked_Access -- see 13.10), the expected type shall be
+>     a single access type whose designated type covers the type of
+>     the prefix, or whose designated profile is type conformant
+>     with that of the prefix. [The prefix of such an attribute_reference
+>     is never interpreted as an implicit_dereference or parameterless
+>     function_call (see 4.1.4).] The designated type or profile of the
+>     expected type of the attribute_reference is the expected type or
+>     profile for the prefix.
+
+I believe there is a serious problem with this wording.  It seems to me that
+we have lost the ability to use 'Access as a controlling parameter of a
+dispatching call.  Essentially, the changes that we did in AI 127 should
+have been taken into account when writing the wording section for AI 235.
+
+Consider the following code fragment:
+
+     type T is tagged null record;
+     function F (X : access T) return Boolean;
+
+     X : T;
+     Y : T'Class := X;
+     Z : Boolean := F (Y'Access);
+
+It appears that the attribute Access in the declaration of Z is illegal
+according to the new wording.  The expected type for Y'Access is the
+anonymous access type access T, and the designated type T does not cover the
+type of the prefix, T'Class, so the new 3.10.2(2) makes the attribute
+illegal.  We don't even get as far as looking at RM95 8.6(22-25).
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 16, 2000 6:58 PM
+
+Yes, I agree. AI-127 is part of the corrigendum, so it has priority here.
+Fixing this wording is very hard (which probably why you didn't attempt it!).
+
+> Consider the following code fragment:
+>
+>      type T is tagged null record;
+>      function F (X : access T) return Boolean;
+>
+>      X : T;
+>      Y : T'Class := X;
+>      Z : Boolean := F (Y'Access);
+>
+> It appears that the attribute Access in the declaration of Z
+> is illegal according to the new wording.
+
+He-he: it is illegal according to *any* wording, original, corrigendum, or
+AI-235. Because Y isn't aliased. :-)
+
+I assume you meant:
+
+	Y : aliased T'Class := X;
+
+> The expected type for Y'Access is the anonymous access type access T,
+> and the designated type T does not cover the type of the prefix, T'Class,
+> so the new 3.10.2(2) makes the attribute illegal.  We don't even get as
+> far as looking at RM95 8.6(22-25).
+
+I don't know what 8.6 has to do with it. The change for AI-127 (according to the
+corrigendum) is in 3.10.2(27) (with a small change to 3.10.2(24) to define
+@i<D>):
+
+ * If @i<A> is a named access type and @i<D> is a tagged type, then the
+   type of the view shall be covered by @i<D>; if @i<A> is anonymous and
+   @i<D> is tagged, then the type of the view shall be either @i<D>'Class
+   or a type covered by @i<D>; if @i<D> is untagged, then the type of the
+   view shall be @i<D>, and @i<A>'s designated subtype shall either
+   statically match the nominal subtype of the view or be discriminated
+   and unconstrained;
+
+The change to 3.10.2(2) makes most of this unnecessary; it just echoes the
+resolution rule. (We do need the untagged part.)
+
+The best fix I can come up with is (but it's incredibly awkward):
+
+Replace 3.10.2(2) with:
+   For an attribute_reference with attribute_designator Access (or
+   Unchecked_Access -- see 13.10), the expected type shall be
+   a single access type whose designated type covers the type of
+   the prefix, or, if the type of the prefix is D'Class, whose designated
+   type is D, or whose designated profile is type conformant with that of
+   the prefix. [The prefix of such an attribute_reference is never
+   interpreted as an implicit_dereference or parameterless function_call
+   (see 4.1.4).] The designated type or profile of the expected type of the
+   attribute_reference is the expected type or profile for the prefix.
+
+With this scheme, we'd probably be best off leaving 3.10.2(27) alone (we still
+need the rule about named vs. anonymous access types, along with the untagged
+type rule). I don't think we want to try to use whether or not the type is
+anonymous in resolution, even though it still affects legality.
+
+We can't name the type D in 3.10.2(2) like we did in 3.10.2(27), because
+access-to-subprogram types also come through 3.10.2(2), and they don't have a
+designated type.
+
+I'd prefer to use words for the "D'Class" garbage, but I can't find any that
+mean what I need: "...covers the type of the prefix or is the xxxx type of the
+prefix if the prefix has a classwide type, or whose...". What the heck *is* the
+name for the type represented by D in D'Class for a classwide type? The closest
+I can come is "specific" type, but I don't think that is right. Perhaps there
+isn't one, but perhaps there should be?
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent