CVS difference for ais/ai-00306.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00306.txt

--- ais/ai-00306.txt	2002/08/29 03:33:21	1.1
+++ ais/ai-00306.txt	2002/10/10 17:41:47	1.2
@@ -1,6 +1,7 @@
-!standard  4.3.2 (04)                                  02-08-28  AI95-00306/00
+!standard  4.3.2 (04)                                  02-10-09  AI95-00306/01
 !standard  4.3.2 (05)
 !class binding interpretation 02-08-28
+!status work item 02-10-09
 !status received 02-08-07
 !qualifier Error
 !priority Low
@@ -9,12 +10,12 @@
 
 !summary
 
-If the ancestor_part of an aggregate is an expression, the expression must have
-a specific tagged type.
+If the ancestor_part of an aggregate is an expression, the expression must
+not be dynamically tagged.
 
 !question
 
-Is the aggregate in the following example illegal?
+Is the aggregate in the following example illegal? (Yes.)
 
    package Foo is
 
@@ -49,7 +50,7 @@
 
 This appears to be legal, because the type of the
 ancestor expression is T, and the aggregate's type (TT) is derived
-from T (through one or more record extensions...).  So this appears
+from T (through one or more record extensions...). So this appears
 to be legal in spite of the fact that F (X) is a dispatching call.
 
 It seems this should be illegal, as it would require the expression object of
@@ -63,12 +64,72 @@
 (See summary.)
 
 !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:
 
-(* TBD *)
+Revise the second sentence of 4.3.2(4) to read:
 
+  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
 
-(* TBD *)
+The current rules for resolution of an ancestor expression in an
+extension aggregate permit the expression to be dynamically tagged.
+This is because the name resolution rule in 4.3.2(4) specifies that
+the expression can be of any type in the class of nonlimited tagged
+types, and the restriction in 3.9.2(9/1) that disallows dynamically
+tagged expressions only applies if "the expected type for an expression
+or name is some specific tagged type". If an ancestor expression for
+an aggregate of type TT is a dispatching call of the form F (X),
+returning a specific type T that is an ancestor of type TT, then
+it will satisfy the resolution rule in 4.3.2(4) as well as the
+derivation rule of 4.3.2(5).
+
+It's clearly undesirable to allow a dispatching call as an ancestor
+expression, since logically the result of such a call can be of any
+type in the class. Even if the semantics were specified to involve
+a conversion to the specific root type, although this would be
+well-defined, it would be error-prone and probably not reflect the
+intent of the programmer (it's more likely to indicate a coding
+mistake).
+
+One approach to fixing the rules is to try and make a change that
+allows the restriction of 3.9.2(9/1) to apply. The simplest change
+seems to be to revise 4.3.2(4) to require an expression of any
+specific nonlimited tagged type rather than any nonlimited tagged
+type. The problem is that the rule in 3.9.2(9/1) is stated to only
+apply if "the expected type is some specific tagged type". However
+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.
+
+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.
 
 !ACATS test
 
@@ -180,6 +241,63 @@
 GNAT seems to have real problems with this case and variants on it.  I
 won't submit a bug report until I know what the right result is, but one
 problem seems to be an indefinite loop in type resolution..
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, October 9, 2002  8:53 PM
+
+This is a draft of AI-306.  Two possible wording changes are discussed,
+so after we agree on the right fix it should be possible to condense
+the !wording and !discussion sections.
+
+(* Editor's note: This is version 01 of the AI. *)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, October 9, 2002  9:52 PM
+
+I prefer one new simple rule to adding complexity
+to an already complex rule. Hence, I prefer
+solution 1.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, October 10, 2002  12:19 PM
+
+> 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.}
+
+I like that.
+
+> 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 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.
+
+Whether it works or not, it seems undesirable to me.  I don't like
+making the Name Resolution rules too precise.  E.g, if there's a
+function F that return T'Class, and a different F that returns T,
+I don't want the compiler to pick one of them -- I want it to be
+ambiguous.  This rule is already too precise, IMHO.  I would have left
+out the part about "nonlimited" and "tagged", which only serve to aid in
+the writing of obscure code.  Adding "specific" just makes it worse.
+
+So I prefer the First Solution.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent