CVS difference for ais/ai-00306.txt

--- ais/ai-00306.txt	2002/10/10 17:41:47	1.2
+++ ais/ai-00306.txt	2003/03/04 04:56:23	1.3
@@ -1,12 +1,13 @@
-!standard  4.3.2 (04)                                  02-10-09  AI95-00306/01
-!standard  4.3.2 (05)
+!standard  4.3.2 (05)                                  03-02-18  AI95-00306/02
 !class binding interpretation 02-08-28
+!status Amendment 200Y 03-02-18
+!status ARG Approved 7-0-1  03-02-09
 !status work item 02-10-09
 !status received 02-08-07
 !qualifier Error
 !priority Low
 !difficulty Medium
-!subject Classwide extension aggregate expressions
+!subject Class-wide extension aggregate expressions
 
 !summary
 
@@ -41,7 +42,7 @@
       end F;
 
       procedure P (X : in T'Class) is
-         V : TT := (F (X) with null record);  -- Error?
+         V : TT := (F (X) with null record);  -- Error? (Yes.)
       begin
          null;
       end P;
@@ -65,26 +66,10 @@
 
 !wording
 
-First solution:
-
 Add the following rule as the second sentence of 4.3.2(5):
-
-  {If the ancestor_part is an expression, it shall not be dynamically tagged.}
-
-The above sentence definitely seems to fix the problem, but the following
-change would avoid adding a new rule:
-
-Second solution:
 
-Revise the second sentence of 4.3.2(4) to read:
+  If the ancestor_part is an expression, it shall not be dynamically tagged.
 
-  If the ancestor_part is an expression, it is expected to be of any {specific}
-  nonlimited tagged type.
-
-However, it's not clear that the second proposed solution will work,
-as the "expected to be of any ... type" wording still seems to prevent
-3.9.2(9/1) from applying. See discussion.
-
 !discussion
 
 The current rules for resolution of an ancestor expression in an
@@ -116,20 +101,23 @@
 the wording in 4.3.2(4) talks about expecting a type in a class of
 types, and that doesn't seem to jibe with expecting some specific
 type. It's not clear how 3.9.2(9/1) could be cleanly reworded to
-cover this case.
+cover this case. Thus, this approach was rejected.
+
+Therefore, we add an additional legality rule to 4.3.2(5).
+
+!corrigendum 4.3.2(5)
 
-If it's decided that it is sufficient to simply add "specific"
-to 4.3.2(4), then this is clearly the preferred wording change.
-Note that this will have an effect on the set of interpretations
-that are considered for the ancestor expression (now excluding
-any interpretations with class-wide results), but that can only
-prevent ambiguities, not add any new ones, so it's compatible.
-
-If a revision to 4.3.2(4) isn't considered sufficient, then a new
-legality rule is needed. The rule to be added is to require in
-4.3.2(5) that "If the ancestor_part is an expression, it shall
-not be dynamically tagged". This clearly fixes the problem,
-but at the cost of an additional rule.
+@drepl
+If the @fa<ancestor_part> is a @fa<subtype_mark>, it shall denote a specific
+tagged subtype. The type of the @fa<extension_aggregate> shall be derived from
+the type of the @fa<ancestor_part>, through one or more record extensions (and
+no private extensions).
+@dby
+If the @fa<ancestor_part> is a @fa<subtype_mark>, it shall denote a specific
+tagged subtype. If the @fa<ancestor_part> is an @fa<expression>, it shall not
+be dynamically tagged. The type of the @fa<extension_aggregate> shall be
+derived from the type of the @fa<ancestor_part>, through one or more record
+extensions (and no private extensions).
 
 !ACATS test