JEP325: Switch expressions spec

[Kevin Bourrillion]

If one of the patterns is a constant expression or enum constant that is
> equal to the value of the selector expression, then we say that the pattern
> *matches*.
>

I think "equal" is ambiguous for strings (and will be for doubles when they
happen).


switch (s) {
> // Even default does not match
> // Will throw an exception
> default:
> System.out.println("It's a string");
> }

I think it would be good to show the modified example that uses `case
null: default:` together in order to produce the expected default
behavior.



> *A pattern label can contain multiple patterns, and is said to match if
> any one of these patterns matches. The pattern label can then be seen to be
> a disjunction of its constituent patterns.*switch (day) {
> case SATURDAY, SUNDAY:
> // matches if it is a Saturday OR a Sunday
> System.out.println("It's the weekend!");
> }

Were we considering allowing `case *something*, default:` or `default,
case *something*:`? Of course you would never ever actually *need*
this... except in the one case that *something* is null. In a switch
expression it would be sad to be forced to revert to the old syntax
for only this reason.

If we're not allowing that, perhaps that's worth pointing out.


Example 14.11-1. Fall-Through in the switch Statement

Since there's a whole section on this, it might be helpful to point out
that when multiple labels are used with no intervening code (not using the
new comma feature), this is* not* considered fall-through. Everyone gets
confused about the terminology. Meh...



> Evaluation of an expression can produce side effects, because expressions
> may contain embedded assignments, increment operators, decrement operators,
> and method invocations.
> *In addition, lambda expressions and switch expressions have bodies that
> may contain arbitrary statements.*


A lambda "contains" statements *physically*, but nothing gets executed. If
anything, it is anonymous *classes* that belong here (though maybe,
arguably, that would be covered if "method invocations" was changed to
"method or constructor invocations"?).

Suggestion: "... because expressions may contain embedded assignments,
increment operators, decrement operators, and method or constructor
invocations, as well as arbitrary statements nested inside a switch
expression."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180418/be1a4f9d/attachment.html>