CVS difference for ai05s/ai05-0147-1.txt
--- ai05s/ai05-0147-1.txt 2010/08/20 04:07:16 1.19
+++ ai05s/ai05-0147-1.txt 2010/10/13 03:55:41 1.20
@@ -1,4 +1,4 @@
-!standard 4.3.3(15) 10-08-19 AI05-0147-1/12
+!standard 4.3.3(15) 10-10-12 AI05-0147-1/13
@@ -91,8 +91,24 @@
+The basic idea is that a conditional expression takes the form
+(if B then E1 else E2)
+Note that there is no end if. However, a conditional
+expression is always surrounded by parentheses. In most
+contexts where there are already parentheses, then only one
+pair is needed, thus a procedure call might be
+P(if B then E1 else E2);
+Elsif parts are allowed thus
+P(if B1 then E1 elsif B2 then E2 else E3);
+If the type of the expression is boolean then an else part of
+the form else True can be omitted.
Change the . to a ; at the end of 4.3.3(15), and add a following bullet:
@@ -173,14 +189,16 @@
and conditional_expressions. Then, that could be used in all of the syntax
which could consist of parens directly around an expression. We did not do
that because of the large amount of change required. A complete grammar is
-given in AI05-0147-1.
+given in AI05-0147-1. [Editor's note: That's in the discussion section of
AARM Implementation Note: Implementers are cautioned to consider error
detection when implementing the syntax for conditional_expressions.
Conditional_expressions and if_statements are very similar syntactically,
and simple mistakes can appear to change one into the other, potentially
causing errors to be moved far away from their actual location.
+The absence of "end if" to terminate a conditional_expression also may make
+error handling harder.
Name Resolution Rules
@@ -232,7 +250,7 @@
(treating a final else as elsif True then), until one evaluates to True or
all conditions are evaluated and yield False. If a condition evaluates to
True, the associated *dependent_*expression is evaluated, converted to the
-type of the conditional_expression, and resulting value is the value of the
+type of the conditional_expression, and the resulting value is the value of the
conditional_expression. Otherwise, the value of the conditional_expression is
@@ -380,7 +398,7 @@
We augment the resolution rule for *dependent_*expressions with additional
rules defining the type of the entire expression. If no such type can be
-determined, then the expression is illegal. This prevent cases like:
+determined, then the expression is illegal. This prevents cases like:
type Some_Boolean is new Boolean;
function Foo return Some_Boolean;
@@ -391,6 +409,11 @@
if (if Cond then Var > 10 else Foo) then ... -- Illegal as no type can be
-- determined for the conditional_expression.
+In this case, "Var > 10" has type Boolean while Foo has type Some_Boolean. No
+unique type can be determined for the conditional expression, so it is illegal,
+even though both of the expressions would be OK if used directly as conditions
+(the condition of an if_statement requires "any boolean type").
Note that if a type is identified by context, only convertability is required
of the *dependent_*expressions. This allows implicit conversions (including to
class-wide and access types) to work properly. If the types of the
@@ -399,9 +422,10 @@
(if Cond then Var else 0)
(if Ptr /= null then Ptr.all else null)
- T'Class'(if Cond then DT'(A) else T'(B) -- Where DT is derived from T
-which is definitely not what we want.
+ T'Class'(if Cond then DT'(A) else T'(B)) -- Where DT is derived from T
+It would be very annoying if such examples were illegal.
Finally, we have a rule that distributes the target of a type conversion
to the *dependent_*expressions. This means that
T(if Cond then A else B)
@@ -442,7 +466,7 @@
(if False then Some_Function_Call / 0 else 123) is not static.
Note that while (if N = 0 then Some_Function_Call else 10_000 / N)
-is not static even if N is static, the expression is alway legal. That's
+is not static even if N is static, the expression is always legal. That's
because the else expression is not evaluated if N is 0 (it would be illegal
if it was).
@@ -464,7 +488,7 @@
-We allow conditional_expressions in build-in-place contexts subject the normal
+We allow conditional_expressions in build-in-place contexts subject to the normal
rules for operands. The model is that a conditional_expression works like a
set of parentheses; it does not copy any objects or create any temporaries on its
@@ -8765,3 +8789,4 @@
Makes sense to me.
Questions? Ask the ACAA Technical Agent