CVS difference for ai05s/ai05-0147-1.txt
--- ai05s/ai05-0147-1.txt 2010/04/29 06:27:42 1.16
+++ ai05s/ai05-0147-1.txt 2010/06/13 04:47:08 1.17
@@ -8453,3 +8453,156 @@
We'll discuss the other issues tomorrow.
****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, May 11, 2010 3:56 PM
+
+> I think there is a misunderstanding here about a fairly important point.
+> This proposed wording is in addition to, not instead of, the following
+> wording in the existing version of the AI:
+> If a conditional_expression is expected to be of a type T, the
+> expected type for each dependent_expression of the
+> conditional_expression is T. If a conditional_expression shall
+> resolve to a type T, each dependent_expression
+> shall resolve to T.
+>
+
+Incidentally, note the interaction between this rule and the new legality rule
+of AI05-0102:
+
+ If the expected type of a construct is T1 and the actual type of the
+ construct is T2, then T2 shall be convertible to T1 (see 4.6).
+
+This brings up cases like
+
+ type Ref is access Integer;
+ X, Y : Ref;
+ begin
+ declare
+ type Rec is record
+ Z : access Integer;
+ end record;
+ R : Rec;
+ begin
+ X := (if Cond then Y else R.Z);
+
+which this rule would cause to be rejected (which is good).
+
+
+Here is slightly revised wording proposal:
+
+----
+
+Name Resolution rules:
+
+If a conditional_expression is expected to be of a type T, then each
+dependent_expression of the conditional_expression is expected to be of type T.
+Similarly, if a conditional expression is expected to be of some class of types,
+then each dependent_expression of the conditional_expression is subject to the
+same expectation. If a conditional_expression shall resolve to be of a type T,
+then each dependent_expression shall resolve to be of type T.
+
+The type of a conditional expression is determined by the types of its dependent
+expressions as follows:
+ o if all dependent expressions are of the same type, then
+ that type is the type of the conditional expression;
+ o otherwise, if at least one dependent expression is of a
+ non-universal type and every other dependent expression is
+ either of that type or of a universal type which covers
+ that non-universal type, then the non-universal type is the
+ type of the conditional expression;
+ o otherwise, if the conditional expression is expected to
+ be of a single non-universal type, or if it shall resolve
+ to be of a single non-universal type, then that type is
+ the type of the conditional expression.
+
+----
+
+Discussion:
+
+Randy says that this we don't use "shall" in name resolution rules.
+so I used "the type of a conditional expression is determined ...
+as follows". Do I need to add an explicit legality rule saying that the type of
+a conditional expression shall be determined, or what? I'm trying to capture the
+idea that the program is illegal if these rules do not determine the type of a
+conditional expression.
+
+----
+
+Given
+
+ X : Discriminated (D => (if ... then null else new Designated));
+
+is the allocated object (if any) a coextension?
+I'm not sure, but I think the rule ought to be the same as for a parenthesized
+expression, as in
+
+ X : Discriminated (D => (new Designated));
+
+----
+
+If we want to allow
+
+ X1, X2, X3, X4 : access Integer := ... ; -- 4 different types
+ Flag : Boolean := (if ... then X1 else X2)
+ = (if ... then X3 else X4);
+
+then we might add either another item to the bulleted list above, either
+
+ o otherwise, the type of the conditional expression is the
+ type of the first dependent expression which is not
+ of a universal type.
+
+coupled with a new legality rule
+
+ The types of every pair of dependent expressions of a
+ given conditional expression must be convertible.
+
+or probably (for reasons explained below) more restricted forms of the above two
+rules such that they only apply if the conditional expression is expected to be
+of type Universal_Access.
+
+----
+
+Randy wants the following example to work:
+
+ type T is tagged ...
+ type S is new T with ...;
+
+ B : S;
+ C : T;
+
+ function F (Cond : in Boolean) return T'Class is
+ begin
+ return (if cond then B else C);
+ end F;
+
+I believe this does work with this wording, although it wouldn't if we went for
+the unrestricted form of the "types of every pair of dependent expressions ...
+must be convertible" rule mentioned above.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, May 11, 2010 4:24 PM
+
+> Randy says that this we don't use "shall" in name resolution rules.
+
+We certainly say "shall resolve to" in several name resolution rules. And if
+you look at 6.4(9), you'll see other uses of "shall." I wonder what Randy meant
+by this... In my mind, use "shall" if it helps in a name resolution rule. The
+meaning of "shall" is that only interpretations that satisfy all of the "shall"s
+are considered, and you ultimately get an error only if there is not exactly one
+interpretation that satisfies all of the name resolution rules.
+
+> so I used "the type of a conditional expression is determined ...
+> as follows". Do I need to add an explicit legality rule saying that
+> the type of a conditional expression shall be determined, or what? I'm
+> trying to capture the idea that the program is illegal if these rules
+> do not determine the type of a conditional expression.
+
+If you follow the lead of "6.4(9)" you can, to be extra clear, say "this rule is
+an overloading rule (see 8.6)." But that is redundant with the "Name Resolution
+Rules" subheading, which now seems to be a pretty official part of the standard.
+
+****************************************************************
Questions? Ask the ACAA Technical Agent