CVS difference for ai05s/ai05-0147-1.txt

Differences between 1.16 and version 1.17
Log of other versions for file 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