CVS difference for ais/ai-00332.txt

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

--- ais/ai-00332.txt	2003/07/26 01:16:55	1.1
+++ ais/ai-00332.txt	2003/07/26 03:26:03	1.2
@@ -1,5 +1,4 @@
-!standard  4.7  (03)                                   03-07-25  AI95-00320/01
-!standard  8.6  (27)
+!standard  4.7  (03)                                   03-07-26  AI95-00332/02
 !class binding interpretation 03-07-25
 !status work item 03-07-25
 !status received 03-03-17
@@ -48,8 +47,8 @@
 Another question regarding qualified expressions:
 
     type T1 is record ... end record;
-    type Acc_1 is access all record;
-    type Acc_2 is access all record;
+    type Acc_1 is access all T1;
+    type Acc_2 is access all T1;
 
     X : aliased T1;
 
@@ -73,82 +72,57 @@
 (See Wording.)
 
 !wording
-
-Add an AARM note to 4.7(3):
-
-This means that the operand must have exactly the type of the subtype_mark.
-This is different than having an expected type (as for most other resolution
-rules), which allow classwide types to match specific types.
 
-Add the following to 8.6(27):
+Replace 4.7(3) by:
 
-In particular, when a single type is required, the operand of a
-qualified_expression identifies a single type (namely, the type specifed by the
-subtype_mark), and that type is the expected type of the operand.
+The expected type of the operand (the expression or aggregate) is
+the type determined by the subtype_mark. Furthermore, notwithstanding what
+this International Standard says elsewhere, the operand shall have the type
+determined by the subtype_mark, or a universal type that covers it.
 
 AARM Note:
-To be honest: A qualified expression's operand does not have an expected type,
-unless a single type is required.
-
-!discussion
 
-"shall resolve to" is defined in 8.6. It clearly applies here, so that a
-classwide operand cannot be used with a specific type qualified expression.
+This means that the operand must have exactly the type of the subtype_mark
+(or a universal type). This is different most other contexts, which allow
+classwide types to match specific types.
 
-However, the "expected type" of the operand is not defined. This matters only
-in cases where a single expected type is required (such as an Obj'Access
-attribute). We clearly want to allow 'Access attributes in a qualified
-expression (it may be the only way to insure that they resolve), and the
-expression clearly meets the tests for a single type. However, since it does
-not have an "expected type", we need to explicitly say that it is OK.
-
-It would be cleaner to define the expected type of the operand of a qualified
-expression for all cases, but that would allow classwide expressions to match
-specific type qualifications, which we do not want to allow.
-
-It might appear that we could put this text in 3.10.2(2), which is where the
-resolution of Obj'Access is defined. However, other constructs also use
-"expected type is a single blah type", such as null, character literals, and
-string literals. We don't want to be defining all of these places.
+!discussion
 
-An alternative would be to replace 4.7(3) by:
+Clearly we want the Access attribute, null, character literals, and so on,
+to work in qualified expressions. The entire point of qualified expressions
+is to resolve ambiguity in expressions, and the purpose would be severely
+compromised if some types of expressions could not be used in them.
+
+However, the "expected type" of the operand of a qualified expression is not
+defined. In order for the resolution rules for the above cases to work, the
+expected type needs to be defined. These are just some of the cases where the
+expected type is used in other rules.
+
+On the other hand, just doing that would trigger the rules of 8.6(22-25). But
+we definitely do not want the operand of a qualified expression to be
+a classwide type if the qualifying type is a specific type. Moreover, a
+legality rule would make some qualified expressions ambiguous, which would
+make qualified expressions less useful for eliminating ambiguity.
 
-The expected type of the operand (the expression or aggregate) is
-the type determined by the subtype_mark. The operand shall have the type
-determined by the subtype_mark, or a universal type that covers it.
-
-This is goofy, because we're giving the rule twice, with the second more
-restrictive that the first. The second rule must be a name resolution rule;
-if it was a legality rule ambiguities would be introduced, which would be
-contrary to the purpose of qualified expressions.
+Thus we adopt a rule which defines the expected type of the operand, and then
+adds additional constraints on the type of the operand.
 
-!corrigendum 8.6(27)
+!corrigendum 4.7(03)
 
 @drepl
-When the expected type for a construct is required to be a @i<single> type in a
-given class, the type expected for the construct shall be determinable solely
-from the context in which the construct appears, excluding the construct
-itself, but using the requirement that it be in the given class; the type of
-the construct is then this single expected type. Furthermore, the context shall
-not be one that expects any type in some class that contains types of the given
-class; in particular, the construct shall not be the operand of a
-@fa<type_conversion>.
+The @i<operand> (the @fa<expression> or @fa<aggregate>) shall resolve to be of
+the type determined by the @fa<subtype_mark>, or a universal type that covers
+it.
 @dby
-When the expected type for a construct is required to be a @i<single> type in a
-given class, the type expected for the construct shall be determinable solely
-from the context in which the construct appears, excluding the construct
-itself, but using the requirement that it be in the given class; the type of
-the construct is then this single expected type. In particular, when a single
-type is required, the operand of a @fa<qualified_expression> identifies a
-single type (namely, the type specifed by the @fa<subtype_mark>), and that type
-is the expected type of the operand. Furthermore, the context shall
-not be one that expects any type in some class that contains types of the given
-class; in particular, the construct shall not be the operand of a
-@fa<type_conversion>.
+The expected type of the @i<operand> (the @fa<expression> or @fa<aggregate>) is
+the type determined by the @fa<subtype_mark>. Furthermore, notwithstanding what
+this International Standard says elsewhere, the operand shall have the type
+determined by the @fa<subtype_mark>, or a universal type that covers it.
 
 !ACATS test
 
-Existings ACATS tests test resolution.
+Existing ACATS tests test resolution of qualified expressions, including
+various kinds of literals.
 
 !appendix
 
@@ -481,6 +455,57 @@
 
 Seems better to me.  Maybe the goofiness can be attenuated by starting
 the second sentence with "Furthermore, ".
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, July 25, 2003  8:02 PM
+
+>     type T1 is record ... end record;
+>     type Acc_1 is access all record;
+>     type Acc_2 is access all record;
+
+(Randy, if that's text from the AI then be sure to correct
+the access types to say "all T1" rather than "all record".:)
+
+> An alternative would be to replace 4.7(3) by:
+>
+> The expected type of the @i<operand> (the @fa<expression> or @fa<aggregate>)
+> is the type determined by the @fa<subtype_mark>. The operand shall have the
+> type determined by the @fa<subtype_mark>, or a universal type that covers
+> it.
+>
+> This is goofy, because we're giving the rule twice, with the second more
+> restrictive that the first. But maybe it is better??
+
+It seems preferable if the fix can be applied in 4.7(3).  However,
+I'm unclear on how this avoids triggering the 8.6(22-25) expected
+type rules.  It seems like you're just creating a contradiction
+between this new rule and the 8.6 rules, but maybe I'm missing
+a subtlety of the wording that avoids invoking the type resolution
+rules.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, July 25, 2003  8:24 PM
+
+That's why I thought it was goofy.
+
+OTOH, Bob's suggestion of "Furthermore, " helps. We could even go so far as
+"Notwithstanding", but that seems like overkill:
+
+The expected type of the @i<operand> (the @fa<expression> or @fa<aggregate>) is
+the type determined by the @fa<subtype_mark>. Furthermore, notwithstanding what
+this International Standard says elsewhere, the operand shall have the type
+determined by the @fa<subtype_mark>, or a universal type that covers it.
+
+That does eliminate all ambiguity, though. Maybe that IS the solution; it's not
+as goofy as the first one.
+
+****************************************************************
+
+
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent