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

Differences between 1.14 and version 1.15
Log of other versions for file ai05s/ai05-0147-1.txt

--- ai05s/ai05-0147-1.txt	2010/04/23 04:15:37	1.14
+++ ai05s/ai05-0147-1.txt	2010/04/29 05:00:28	1.15
@@ -8307,3 +8307,132 @@
 Can't think of any others off the top of my head.
 
 ****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, April 27, 2010  9:04 PM
+
+Steve and I worked on the name resolution rules for conditional expressions.
+The following seems to cover all cases.  The guiding principles were that a
+conditional expression had to have a well- defined type, and that an
+if-statement of the form:
+
+if Cond then
+    X := Exp1;
+else
+    X := Exp2;
+end if;
+
+should be expressible as
+
+X := (if Cond then Exp1 else Exp2);
+
+==========================================
+
+Name resolution rules
+
+The type of a conditional expression shall be determined by the type of its
+dependent expressions as follows:
+
+o If there is a single dependent expression, it must be of a boolean type, and
+  its type is the type of the conditional expression.
+
+o If the types of all dependent expressions are the same, this common type is
+  the type of the conditional expression.
+
+o if all dependent expressions are either of the same non-universal type or of a
+  universal type that covers that type, then the non- universal type is the type
+  of the conditional expression.
+
+o if all dependent expressions (excluding those, if any, which are of type
+  universal_access) are of anonymous access-to-object types such that each pair
+  of the types has statically matching designated subtypes, then the type of the
+  textually first such expression is the type of the conditional expression.
+
+o if all dependent expressions (excluding those, if any, which are of type
+  universal_access) are of anonymous access-to-subprogram types such that each
+  pair of the types has fully conformant profiles, then the type of of the
+  textually first such expression is the type of the conditional expression.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, April 28, 2010  11:58 PM
+
+I don't know if the above is intended to be actual wording, but if it is, I
+detest it. It's been bothering me all day. Let me count the ways that I hate
+this:
+
+(1) I can't see any connection between this and the expected type/shall resolve
+    type of the conditional expression. That has to be defined - all Ada
+    resolution works based on that. Besides, expressions don't necessarily have
+    types (there is no defined type for an aggregate or string literal, for
+    instance; the type comes from the context).
+
+(2) Because of (1), this wording will not allow string literals at all.
+
+(3) This wording duplicates all of the rules for implicit conversions, making a
+    future maintenance hazard.
+
+(4) This wording does not work for class-wide types at all. My original example:
+
+     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); -- Not allowed by the above.
+         if Cond then
+            return B; -- OK
+         else
+            return C; -- OK
+         end if;
+     end F;
+
+This simply is not allowed by the wording you have: B and C are not the same
+type.
+
+(5) This also doesn't allow implicit conversions to named access types from
+    anonymous ones (we allow that now, you know) if they're mixed with a named
+    one. For instance:
+
+    type A is access Integer;
+
+    procedure P (Cond : in Boolean; B : access Integer; C : A) is
+       O : A;
+    begin
+       if Cond then
+          O := B; -- OK
+       else
+          O := C; -- OK
+       end if;
+       O := (if Cond then B else C); -- Illegal, not same type by above.
+    end P;
+
+(6) Since you're not differentiating between "shall resolve to" and "expected
+    type", you're either allowing too much or are not allowing enough in one of
+    the two cases.
+
+(7) Nit-pick: Name Resolution Rules don't use "shall".
+
+I suspect there are more, but I think this should be enough...
+
+To be constructive:
+
+I still think the appropriate rule has to work differently if "any" type is
+expected, or just one type is expected. In the latter case, the type of the
+conditional expression is the expected (or shall resolve to) type. And then the
+dependent_expressions resolve normally to the type of the conditional
+expression.
+
+In the "any" type (including "any numeric", "any boolean", etc) case, you could
+use rules like these, or something simpler depending on how hard you want to
+work.
+
+I realize this is essentially what I had previously proposed, but I think that
+it needed only a minor tweak to deal with the number declaration case (and some
+better wording for "any type"), not a start-over-from-scratch.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent