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

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

--- ai05s/ai05-0147-1.txt	2010/06/13 04:47:08	1.17
+++ ai05s/ai05-0147-1.txt	2010/07/28 05:52:44	1.18
@@ -1,4 +1,4 @@
-!standard 4.3.3(15)                                    10-02-22  AI05-0147-1/10
+!standard 4.3.3(15)                                   10-07-26  AI05-0147-1/11
 !standard 4.4(1)
 !standard 4.4(7)
 !standard 4.5.7(0)
@@ -10,6 +10,8 @@
 !standard 5.3(4)
 !standard 7.5(2.1/2)
 !class amendment 09-03-13
+!status Amendment 2012 10-07-26
+!status ARG Approved  9-0-0  10-06-20
 !status work item 09-03-13
 !status received 09-03-13
 !priority Medium
@@ -117,6 +119,10 @@
 
 4.5.7 Conditional expressions
 
+A conditional_expression selects for evaluation at most one of the enclosed
+*dependent_*expressions, depending on the value of one or more corresponding
+conditions.
+
     Syntax
 
 conditional_expression ::= if condition then *dependent*_expression
@@ -180,25 +186,34 @@
 
 A condition is expected to be of any boolean type.
 
-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.
-
-AARM To Be Honest: T in this rule could be any type in a class of types
-   (including the class of all types), or (for the second rule) an anonymous
-   access type (for renames) or a universal type covering some type (for
-   qualified expressions).
+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.
 
-    Legality Rules
+The possible types of a conditional_expression are further determined as
+follows:
 
-If the expected type of a conditional_expression is any type in a class of types
-(instead of a particular type), all *dependent_*expressions of the
-conditional_expression shall have the same type.
+* If the conditional_expression is the operand of a type conversion, the type of
+  the conditional_expression is the target type of the conversion; otherwise
 
-If there is no "else" *dependent_*expression, all of the *dependent_*expressions
-of the conditional_expression shall be of a boolean type.
+* If all of the *dependent_*expressions are of the same type, the type of the
+  conditional_expression is that type; otherwise
+
+* If a *dependent_*expression is of an elementary type, the type of the
+  conditional_expression shall be covered by that type; otherwise
+
+* If the conditional_expression is expected to be of type T or shall resolve to
+  type T, then the conditional expression is of type T.
+
 
+    Legality Rules
+
+All of the *dependent_*expressions shall be convertible to the type of the
+conditional_expression.
+
 If the expected type of a conditional_expression is a specific tagged type, all
 of the *dependent_*expressions of the conditional_expression shall be
 dynamically tagged, or none shall be dynamically tagged; the
@@ -207,26 +222,28 @@
 the *dependent_*expressions are tag-indeterminate, and is statically tagged
 otherwise.
 
-[Editor's note: We don't try to define the type of the conditional expression;
-it gets complex when implicit conversions are involved. There may not be a
-unique type that is identifiable (especially as dynamically tagged expressions
-might need to be converted to be classwide).]
+If there is no "else" *dependent_*expression, all of the *dependent_*expressions
+of the conditional_expression shall be of a boolean type.
 
     Dynamic Semantics
 
-For the execution of a conditional expression, the condition specified after
+For the execution of a conditional_expression, the condition specified after
 if, and any conditions specified after elsif, are evaluated in succession
 (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 and its value
-is the value of the expression. Otherwise, the value of the expression
-is True.
+True, the associated *dependent_*expression is evaluated, converted to the
+type of the conditional_expression, and resulting value is the value of the
+conditional_expression. Otherwise, the value of the conditional_expression is
+True.
 
 [Editor's note: This is nearly a copy of 5.3(5). I left the clunkyness
-intact. Note that the last otherwise can be true only for a boolean
-conditional expression, as an "else" is required in all other cases.]
+intact.]
 
+AARM Ramification: "Else" is required unless the conditional_expression has
+a boolean type, so the last sentence can only apply to conditional_expressions
+with a boolean type.
 
+
 Add after 4.9(12):
 
 * A conditional_expression all of whose conditions and dependent_expressions are
@@ -249,7 +266,7 @@
 
 AARM Discussion: We need the "of the conditional_expression" here so there
 is no confusion for nested conditionals; this rule only applies to the
-conditions and *dependent_*expressions of a single conditional expression.
+conditions and *dependent_*expressions of a single conditional_expression.
 
 AARM Reason: We need the last bullet so that only a single *dependent_*expression
 is evaluated in a static conditional expression if there is more than one
@@ -351,7 +368,7 @@
 (That's made harder by the complete absence of such rules in the Ada Standard,
 so there is nothing to copy.)
 That is, whatever the context expects/requires is what is expected/required of
-the dependent expressions.
+the *dependent_*expressions.
 
 We considered aggregate-like resolution, but that would have used too little of
 the context. For instance:
@@ -361,9 +378,9 @@
 
 would be ambiguous because the operand of & could be either String or Character.
 
-We augment the resolution rule with legality rules to ensure that all of the
-dependent_expressions have the same type if the context does not identify a
-particular type. This is needed to prevent cases like:
+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:
 
     type Some_Boolean is new Boolean;
     function Foo return Some_Boolean;
@@ -371,17 +388,27 @@
     Cond : Boolean := ...;
     Var  : Natural := ...;
 
-    if (if Cond then Var > 10 else Foo) then ... -- Illegal by legality rule.
+    if (if Cond then Var > 10 else Foo) then ... -- Illegal as no type can be
+	-- determined for the conditional_expression.
 
-Note the we do allow the types to differ if a unique type is identified by the
-context; this allows implicit conversions (including to class-wide and access
-types) to work properly. If the types had to be the same, all of the
-following would be illegal:
+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
+*dependent_*expressions had to be the same, all of the following would be
+illegal:
+
     (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.
 
+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)
+is legal if
+    T(if Cond then T(A) else T(B)
+is legal.
+
 We also have a rule to disallow mixing statically tagged and dynamically
 tagged expressions in the same conditional_expression; that makes enforcing
 3.9.2(8) possible.
@@ -448,7 +475,7 @@
 
 ----
 
-The English-language syntax rule in 4.57 could, as noted in the AARM note, be
+The English-language syntax rule in 4.5.7 could, as noted in the AARM note, be
 implemented by modifying the BNF. We believe that it is equivalent to modifying
 the BNF as follows:
 
@@ -498,8 +525,8 @@
         singleton_list
 
 We chose not to make this modification because it is a huge change to the BNF
-grammar, and in addition would require a lot of English text that refers to
-syntactic categories to change.
+grammar, and in addition would require changing a lot of English text that
+refers to syntactic categories.
 
 !examples
 
@@ -527,7 +554,86 @@
              (if Num_Errors = 1 then "error" else "errors")
              & " detected.");
 
+!corrigendum 4.3.3(15)
 
+@drepl
+@xbullet<For a parenthesized @fa<expression>, the applicable index constraint is
+that, if any, defined for the @fa<expression>.>
+@dby
+@xbullet<For a parenthesized @fa<expression>, the applicable index constraint is
+that, if any, defined for the @fa<expression>;>
+
+@xbullet<For a @fa<conditional_expression>, the applicable index constraint for
+each @i<dependent_>@fa<expression> is that, if any, defined for the
+@fa<conditional_expression>.>
+
+!corrigendum 4.4(1)
+
+@drepl
+An @i<expression> is a formula that defines the computation or retrieval of
+a value. In this International Standard, the term "expression" refers to a
+construct of the syntactic category @fa<expression> or of any of the other
+five syntactic categories defined below.
+@dby
+An @i<expression> is a formula that defines the computation or retrieval of
+a value. In this International Standard, the term "expression" refers to a
+construct of the syntactic category @fa<expression> or of any of the following
+categories: @fa<relation>, @fa<simple_expression>, @fa<term>, @fa<factor>,
+@fa<primary>, @fa<conditional_expression>.
+
+!corrigendum 4.5.7
+
+@dinsc
+
+Force a conflict: the real text is in the conflict file.
+
+!corrigendum 4.9(12)
+
+@dinsa
+@xbullet<a short-circuit control form both of whose @fa<relation>s are static
+expressions;
+@dinst
+@xbullet<a @fa<conditional_expression> all of whose @fa<condition>s and
+@i<dependent_>@fa<expression>s are static expressions;
+
+!corrigendum 4.9(33)
+
+@drepl
+A static expression is evaluated at compile time except when it is part of the
+right operand of a static short-circuit control form whose value is determined
+by its left operand. This evaluation is performed exactly, without performing
+Overflow_Checks. For a static expression that is evaluated:
+@dby
+An expression is @i<statically unevaluated> if it is part of:
+
+Rest of the wording is found in the conflict file.
+
+
+!corrigendum 5.3(3)
+
+@ddel
+@xcode<@fa<condition ::= >@i<@ft<boolean_>>@fa<expression>>
+
+!corrigendum 5.3(4)
+
+@ddel
+A @fa<condition> is expected to be of any boolean type.
+
+!corrigendum 7.5(2.1/2)
+
+@drepl
+In the following contexts, an @fa<expression> of a limited type is not permitted
+unless it is an @fa<aggregate>, a @fa<function_call>, or a parenthesized
+@fa<expression> or @fa<qualified_expression> whose operand is permitted by
+this rule:
+@dby
+In the following contexts, an @fa<expression> of a limited type is not permitted
+unless it is an @fa<aggregate>, a @fa<function_call>, a parenthesized
+@fa<expression> or @fa<qualified_expression> whose operand is permitted by this
+rule, or a @fa<conditional_expression> all of whose
+@i<dependent_>@fa<expression>s are permitted by this rule:
+
+
 !ACATS test
 
 ACATS B and C tests are needed.
@@ -8604,5 +8710,58 @@
 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.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, July 26, 2010  10:06 PM
+
+The wording Tucker proposed at Valencia and the ARG approved includes:
+
+Dynamic Semantics
+
+All of the dependent expressions are converted to the type of the conditional
+expression.
+
+But this makes no sense, because we're only going to evaluate *one*
+dependent_expression (whichever one is selected by the conditions). We're surely
+not going to evaluate all of those expressions, convert them at runtime, and
+then throw the result away!
+
+Besides, we already have dynamic semantics rules that describes how the
+dependent_expression is selected.
+
+For If_Expressions, this wording is:
+
+For the execution of an if_expression, the condition specified after if, and any
+conditions specified after elsif, are evaluated in succession (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 and its value is the value of the
+expression. Otherwise, the value of the expression is True.
+
+[As noted in the AI, this is nearly a copy of the wording for If statements; I
+left the clunkiness intact. And yes, the last sentence seems weird until you
+remember that the only time "else" can be omitted is when the expression has a
+boolean type. So it can only occur for such an if_expression.]
+
+I think all we want is to add text about the conversion to the existing text:
+
+For the execution of an if_expression, the condition specified after if, and any
+conditions specified after elsif, are evaluated in succession (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 if_expression,
+and resulting value is the value of the if_expression. Otherwise, the value of
+the if_expression is True.
+
+Thoughts??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, July 27, 2010  7:38 AM
+
+Makes sense to me.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent