CVS difference for ai12s/ai12-0214-2.txt

--- ai12s/ai12-0214-2.txt	2019/07/18 04:21:37	1.6
+++ ai12s/ai12-0214-2.txt	2019/09/05 04:13:50	1.7
@@ -1895,3 +1895,171 @@
 from an expression. And it's used a lot in the wording. :-)
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, July 18, 2019  7:11 AM
+
+We should consider simplifying the syntax instead, to only allow one 
+condition, given the ability to use "or else".  I worry that if we start 
+equating "|" and "or else" it will lead to further confusion elsewhere.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, July 18, 2019  1:34 PM
+
+> We should consider simplifying the syntax instead, to only allow one 
+> condition, given the ability to use "or else".  I worry that if we 
+> start equating "|" and "or else" it will lead to further confusion 
+> elsewhere.
+
+I think it's a little late for that (like 40 years, and especially since
+2012). "|" essentially means "or else" in existing (and original) case 
+statements -- that's certainly one of the implementations.
+
+And it definitely means "or else" in a membership as extended in Ada 2012:
+
+    A in B | C
+
+means
+
+    A = B or else A = C
+
+4.5.2(27.1/4) says so as explicitly as possible without mentioning "|":
+
+For the evaluation of a membership test using in whose membership_choice_list 
+has more than one membership_choice, the 
+tested_simple_expression simple_expression of the membership test is evaluated 
+first and the result of the operation is equivalent to that of a sequence 
+consisting of an individual membership test on each membership_choice combined 
+with the short-circuit control form *or else*.
+
+---
+
+You've previously argued that a case alternative is like a membership, and a 
+membership would definitely allow using "|" to separate two conditions:
+
+    A in B > 5 | B < 5
+
+So one would expect
+
+    when B > 5 | B < 5 =>
+
+to be legal (if you believe this similarity is important, which I personally 
+don't).
+
+In a style guide, I would suggest a subtle distinction between "|" and "or 
+else" in this context. Use "|" to separate two logically separate conditions 
+that happen to have the same result, and use "or else" (or "or") when you have 
+to combine two parts of a single logical condition. But of course the generated
+code is pretty much the same.
+
+In any case, I think this particular ship sailed in Ada 2012 (if not long 
+before). And I do think it is important that the two kinds of case statements 
+aren't more different than they have to be, which includes allowing "|" to 
+separate unrelated expressions that happen to need the same action.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, July 18, 2019  2:53 PM
+
+I can see both sides of this argument.  As I said, we should *consider* 
+simplifying the syntax.  I'd be curious what others think. 
+
+I suppose a difference between the use of "or else" and "|" in this context 
+is that the mutual-exclusion requirement applies to "when cond1 | cond2 => 
+whereas it doesn't apply to "when cond1 or else cond2 =>".  That is, you get
+Program_Error if both evaluate to true in the first case, while you silently
+choose the "cond1 or else cond2" alternative in the second.  I guess we need
+to double check the wording about this as well.
+
+In general, I never imagined having multiple conditions in a single 
+alternative, so it looks odd to me.  I could clearly get used to it, but the 
+mutual exclusion implication seems easier to understand when there is only 
+one condition per alternative.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, July 18, 2019  4:14 PM
+
+> I can see both sides of this argument.  As I said, we should
+> *consider* simplifying the syntax.  I'd be curious what others think. 
+
+Same here.
+ 
+> I suppose a difference between the use of "or else" and "|" 
+> in this context is that the mutual-exclusion requirement applies to 
+> "when cond1 | cond2 => whereas it doesn't apply to "when cond1 or else 
+> cond2 =>".  That is, you get Program_Error if both evaluate to true in 
+> the first case, while you silently choose the "cond1 or else cond2"
+> alternative in the second.  I guess we need to double check the 
+> wording about this as well.
+
+This is definitely the case, as the mutual exclusion requirement is worded
+in terms of choice_conditions (by ARG request) and not in terms of 
+conditional_case_expression_alternatives. Specifically:
+
+... If exactly one choice_condition is True, the dependent_expression of the 
+conditional_case_expression_alternative containing this choice_condition is 
+evaluated, converted to the type of the case_expression, and the resulting 
+value is the value of the case_expression. Otherwise (no choice_condition is 
+True, or multiple choice_conditions are True), Program_Error is raised.
+
+So it's more "xor" than "or" in this case.
+
+> In general, I never imagined having multiple conditions in a single 
+> alternative, so it looks odd to me.  I could clearly get used to it, 
+> but the mutual exclusion implication seems easier to understand when 
+> there is only one condition per alternative.
+
+It makes sense to allow multiple conditions, in that one might want to avoid 
+duplication in alternatives. If an alternative is reasonably complex, why 
+would anyone want to duplicate it?
+
+  when Post =>
+    (case is
+     when X.A > 0 | X.A = 0 and X.B > 0 =>
+        True
+     when X.A = 0 and X.B = 0 =>
+        Arg'Old = None
+     when X.A < 0 | X.A = 0 and X.B < 0 =>
+        False);
+
+There are five separate cases here, but some of them share results. Using 
+"or else" would lose information, and no one really remembers what "xor"
+means. In this case, there isn't much penalty to duplicating the alternatives, 
+but what if the dependent_expression is several lines long (common in 
+postconditions)? So I lean toward the current definition (which allows the 
+above).
+
+In any case, I don't feel too strongly about this (even if the above appears 
+that way), so let's hear from others.
+
+****************************************************************
+
+From: Richard Wai
+Sent: Thursday, July 18, 2019  10:59 PM
+
+> > I can see both sides of this argument.  As I said, we should
+> > *consider* simplifying the syntax.  I'd be curious what others think.
+> 
+> Same here.
+
+It is bad enough that we are violating one of the greatest features of regular
+case statements: static safety. I can't see the value in making things any 
+more inconsistent. If regular case statements accept multiple conditions, so 
+should case_expressions, IMO. 
+
+[Editor's note: The rest of this message is found in AI12-0341-1.]
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, July 19, 2019  12:19 AM
+
+I'd rather have '|' on the ground of least surprise, by analogy to the normal 
+case. Also, the mutual exclusion adds value to the construct.
+
+****************************************************************