CVS difference for ais/ai-00332.txt

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

--- ais/ai-00332.txt	2003/07/26 03:26:03	1.2
+++ ais/ai-00332.txt	2003/11/27 02:01:16	1.3
@@ -1,16 +1,17 @@
-!standard  4.7  (03)                                   03-07-26  AI95-00332/02
+!standard  4.7  (03)                                   03-11-25  AI95-00332/03
 !class binding interpretation 03-07-25
 !status work item 03-07-25
 !status received 03-03-17
 !qualifier Omission
 !priority Low
 !difficulty Medium
-!subject Resolution of qualified expressions
+!subject Resolution of qualified expressions and object renamings
 
 !summary
 
 Access attributes, character literals, and other constructs requiring a
-single expected type can be used as the operand of a qualified expression.
+single expected type can be used as the operand of a qualified expression and
+can be renamed.
 
 !question
 
@@ -73,18 +74,22 @@
 
 !wording
 
-Replace 4.7(3) by:
+Replace 8.6(27) by:
 
-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.
+When a construct is one that requires that its expected type be a *single* type
+in a given class, the type of 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 expected type of the
+construct is then this 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 type_conversion.
 
 AARM Note:
 
-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.
+The part of the first sentence after the semicolon serves to define
+the "expected type" for constructs that don't have one (like qualified
+expressions and renames). Otherwise, such constructs wouldn't allow aggregates
+and 'Access.
 
 !discussion
 
@@ -97,27 +102,36 @@
 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.
 
-Thus we adopt a rule which defines the expected type of the operand, and then
-adds additional constraints on the type of the operand.
+Just changing the definition of qualified expression doesn't work, however.
+First, there are other such constructs for objects (object renames and
+selected components come to mind). Fixing every one of them seems like a pain.
+prohibitive. Second, just defining the expected type of a qualified expression
+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
+their primary purpise of eliminating ambiguity.
 
-!corrigendum 4.7(03)
+!corrigendum 8.6(27)
 
 @drepl
-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.
+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>.
 @dby
-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.
+When a construct is one that requires that its expected type be a @fa<single> type
+in a given class, the type of 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 expected type of the
+construct is then this 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>.
 
 !ACATS test
 
@@ -505,7 +519,103 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Sunday, November 16, 2003  8:31 AM
+
+I offered to come up with better wording to fix the
+problem that certain contexts do not specify an expected
+type.  These contexts generally indicate that something
+"shall resolve" to a particular type, and in some cases
+allow a universal type that covers it.
+
+We avoided the "expected type" terminology to bypass the
+rules in paragraph 8.6(21-25) which are looser than
+we would like.  However, this creates problems with the
+legality rule in 8.6(27) which seems to require that an
+expected type be provided by all contexts.
+
+This rule is (currently) relevant to null, character, and string
+literals, to allocators, and to '[Unchecked_]Acccess (any others?).
+
+Here is the current wording for 8.6(27):
+
+  When the expected type for a construct is required to be
+  a *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 type_conversion.
+
+The second sentence seems OK as is.  The first (long ;-) sentence is
+the problem, as it uses the term "expected" three times, and at least
+two of them are problematic.
+
+Here is a possible alternative for this first sentence:
+
+ When a construct is one that requires that its expected type be
+ a *single* type in a given class, the type of 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.
+
+That seems to solve the problem in my view, in that it only mentions
+"expected type" as part of identifying the case we are talking about,
+but doesn't require that the context actually *provide* such an expected
+type.  Note that I have dropped the trailing phrase "the type of the construct
+is then this single expected type," which seems unnecessary with
+this new wording.  The second sentence (which should remain) rules out cases
+where any type in a class is expected, which might require overload
+resolution to deal with cases where there just happens to be only
+one such type in scope.
+
+I'll keep working if others don't like the above rewording, but it
+seems sufficient to me...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, November 16, 2003  8:38 AM
+
+> ...
+> This rule is (currently) relevant to null, character, and string
+> literals, to allocators, and to '[Unchecked_]Acccess (any others?).
+
+I forgot aggregates.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, November 16, 2003  8:47 AM
+
+too bad someone did not forget aggregates when designing the language in
+the first place :-) :-)
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Sunday, November 16, 2003  10:13 AM
+
+As I remember it from my compiler days, aggregates as parameters weren't
+too bad, it was aggregate assignment that was a blinding headache.  I
+just mention it because we are running into exactly the same mess in the
+other thread.  Sometimes the aggregate takes its constraint from the
+target, and sometimes from the aggregate itself, and the compiler
+front-end may have to do a lot of work before it knows which case it is
+dealing with.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 24, 2003  8:46 PM
+
+Yes, I think this works. Thanks for the effort.
 
+BTW, in addition to qualified expressions, object renaming uses the "shall
+resolve to" wording. Prefix calls (AI-252 and 4.1.3) also do, but those are
+restricted to names, so they never trigger this rule.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent