CVS difference for 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