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

--- ai05s/ai05-0188-1.txt	2010/06/04 05:07:19	1.7
+++ ai05s/ai05-0188-1.txt	2010/07/28 05:52:58	1.8
@@ -1,7 +1,9 @@
-!standard 4.5.7(0)                                10-06-03  AI05-0188-1/05
+!standard 4.5.7(0)                                10-07-26  AI05-0188-1/06
 !standard 4.5.8(0)
+!standard 4.9(12)
 !standard 4.9(33)
 !class amendment 09-11-03
+!status Amendment 2012 10-07-26
 !status work item 09-11-03
 !status received 09-11-03
 !priority Low
@@ -92,41 +94,63 @@
 
         conditional_expression ::= if_expression | case_expression
 
-In the Legality Rules, Static Semantics, and Dynamic Semantics rules of 4.5.7
-change conditional_expression to if_expression.
+In 4.5.7, change conditional_expression to if_expression in:
+* The third paragraph of the Legality Rules; and
+* All of the Dynamic Semantics rules.
+
+Replace the introduction of 4.5.7 with:
+
+A conditional_expression selects for evaluation at most one of the enclosed
+*dependent_*expressions, depending on some form of condition. One kind of
+conditional_expression is the if_expression, which selects for evaluation
+a *dependent_*expression depending on the value of one or more corresponding
+conditions. Another kind of conditional_expression is defined in 4.5.8.
 
+
 Add a new clause:
 
 4.5.8 Case expressions
 
-A case_expression selects for evaluation one of a number of alternative
-expressions; the chosen alternative is defined by the value of an expression.
+One kind of conditional_expression is the case_expression, which selects
+for evaluation one of a number of alternative expressions; the chosen
+alternative is defined by the value of a *selector_*expression.
 
     Syntax
 
 case_expression ::=
-    (case expression is
+    (case *selector_*expression is
      case_expression_alternative {,
      case_expression_alternative}
     )
 
+[Editor's note: "selector_" here is a last minute readability change (especially
+needed for 4.9(12)). I also considered "choosing_" (which just seems weird even
+if consistent with "choices"), "deciding_" (also weird), "case_" (which gives
+the same name as the expression as a whole, too confusing), "determining_", and
+"selecting_". Without this, the wording about choice expressions and this
+expression just gets too confusing. I do worry about confusion with select
+statements, although the word selector is used only once relating to such
+statements.
+
+Probably, a similar change should be made to 5.4 (paragraphs 2, 4, 5, 6, 7,
+8, 9, 11, and 12, AARM 10.b and 10.d). This would avoid confusion with the
+expression in paragraph 5, and make it crystal-clear which rules are referred
+to by the last paragraph of the Name Resolution Rules below.]
+
 case_expression_alternative ::=
     when discrete_choice_list =>
         *dependent*_expression
 
     Name Resolution Rules
 
-The expected type for the expression and the discrete_choices are as for case
-statements (see 5.4).
+Redundant[Name Resolution Rules for the type of the case_expression as a whole
+and the types of the *dependent_*expressions are given in 4.5.7.]
+
+AARM Proof: A case_expression is a special case of a conditional_expression, so
+the rules defined for conditional_expressions also apply to case_expressions.
 
-If a case_expression is expected to be of a type T, the expected type for each
-*dependent_*expression of the case_expression is T. If a case_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).
+The expected type for the *selector_*expression and the discrete_choices are
+as for case statements (see 5.4).
 
     Legality Rules
 
@@ -134,40 +158,35 @@
 case_expression shall be static. Redundant[A discrete_choice others, if present,
 shall appear alone and in the last discrete_choice_list.]
 
-The possible values of the expression shall be covered as for case statements
-(see 5.4).
+The possible values of the *selector_*expression shall be covered as for case
+statements (see 5.4).
 
 As for case statements, two distinct discrete_choices of a case_expression shall
 not cover the same value.
 
-If the expected type of a case_expression is any type in a class of types
-(instead of a particular type), all *dependent_*expressions of the
-case_expression shall have the same type.
-
-If the expected type of a case_expression is a specific tagged type, all of the
-*dependent_*expressions of the case_expression shall be dynamically tagged, or
-none shall be dynamically tagged; the case_expression is dynamically tagged if
-all of the *dependent_*expressions are dynamically tagged, is tag-indeterminate
-if all of the *dependent_*expressions are tag-indeterminant, and is statically
-tagged otherwise.
+Redundant[In addition, Legality Rules that apply to all conditional_expressions
+(see 4.5.7) apply to case_expressions.]
 
-AARM Note: There is nothing corresponding to the implicit "else False" for
-if_expressions.
+AARM Proof: A case_expression is a special case of a conditional_expression.
 
     Dynamic Semantics
 
-For the execution of a case expression, the expression specified after case is
+For the execution of a case_expression, the *selector_*expression is
 first evaluated.
 
-If the value of the expression is covered by the discrete_choice_list of some
-case_expression_alternative, then the *dependent*_expression of the _alternative
-is evaluated, and this is the value of the case_expression.
+If the value of the *selector_*expression is covered by the discrete_choice_list of some
+case_expression_alternative, then the *dependent*_expression of the
+case_expression_alternative is evaluated, converted to the type of the
+case_expression, and the resulting value is the value of the
+case_expression.
 
 Otherwise (the value is not covered by any discrete_choice_list, perhaps due to
 being outside the base range), Constraint_Error is raised.
 
 ================
 
+In 4.9(12.1/3) as added by AI05-0147-1, add "*selector_*expression".
+
 AI05-0147-1 calls for the replacement of 4.9(33).
 Add one more bullet:
 
@@ -189,6 +208,91 @@
 !ACATS test
 
 ACATS B and C tests are needed.
+
+!corrigendum 4.5.7
+
+@dinsc
+
+Force a conflict: the real text is in the conflict file.
+
+!corrigendum 4.5.8
+
+@dinsc
+
+One kind of @fa<conditional_expression> is the @fa<case_expression>, which
+selects for evaluation one of a number of alternative @fa<expression>s; the
+chosen alternative is defined by the value of a @i<selector_>@fa<expression>.
+
+@s8<@i<Syntax>>
+
+@xcode<@fa<case_expression ::=
+   >@ft<@b<case> @i<selector_>>@fa<expression >@ft<@b<is>>@fa<
+    case_expression_alternative {,
+    case_expression_alternative}>>
+
+@xcode<@fa<case_expression_alternative ::=
+   >@ft<@b<when>>@fa< discrete_choice_list =@>
+       >@ft<@i<dependent_>>@fa<expression>>
+
+@s8<@i<Name Resolution Rules>>
+
+Name Resolution Rules for the type of the @fa<case_expression> as a whole
+and the types of the @i<selector_>@fa<expression>s are given in 4.5.7.
+
+The expected type for the @i<selector_>@fa<expression> and the @fa<discrete_choice>s
+are as for case statements (see 5.4).
+
+@s8<@i<Legality Rules>>
+
+The @fa<expression>s and @fa<discrete_range>s given as @fa<discrete_choice>s of a
+@fa<case_expression> shall be static. A @fa<discrete_choice> @b<others>,
+if present, shall appear alone and in the last @fa<discrete_choice_list>.
+
+The possible values of the @i<selector_>@fa<expression> shall be covered as for
+case statements (see 5.4).
+
+As for case statements, two distinct @fa<discrete_choice>s of
+a @fa<case_expression> shall not cover the same value.
+
+In addition, Legality Rules that apply to all @fa<conditional_expression>s
+(see 4.5.7) apply to @fa<case_expression>s.
+
+@s8<@i<Dynamic Semantics>>
+
+For the execution of a @fa<case_expression>, the @i<selector_>@fa<expression> is
+first evaluated.
+
+If the value of the @i<selector_>@fa<expression> is covered by the
+discrete_choice_list of some @fa<case_expression_alternative>, then the
+@i<dependent_>@fa<expression> of the @fa<case_expression_alternative> is
+evaluated, converted to the type of the @fa<case_expression>, and the resulting
+value is the value of the case_expression.
+
+Otherwise (the value is not covered by any @fa<discrete_choice_list>, perhaps
+due to being outside the base range), Constraint_Error is raised.
+
+
+!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
+@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.
+
 
 !appendix