Do we need fallthrough in an expression switch, i believe like Stephen that we
don't.
First, as Stephen point in it's example, if we have comma separated cases, we
need less fallthrough and even if we have a code like this
var value = switch(x) {
case 0:
foo();
case 1:
bar();
break 42;
};
one can always rewrite it with comma separated cases and an if
var value = switch(x) {
case 0, 1:
if (x == 0) {
foo();
}
bar();
break 42;
};
There is another reason to not allow fallthrough,
we have rule out all goto-related syntax like break label/continue label from
the expression switch, but we should still allow a fallthrough which is a goto
to the next basic block.
I think we should be coherent here and do not allow the fallthrough in the
expression switch.
Rémi
----- Mail original -----
> De: "Stephen Colebourne" <scolebou...@joda.org>
> À: "amber-dev" <amber-...@openjdk.java.net>
> Envoyé: Lundi 9 Avril 2018 01:58:03
> Objet: Expression switch - an alternate proposal
> What follows is a set of changes to the current expression switch
> proposal that I believe result in a better outcome.
>
> The goal is to tackle four specific things (in order):
> 1) The context as to whether it is a statement or expression switch
> (and thus what is or is not allowed) is too remote/subtle
> 2) Mixing arrows and colons is confusing to read
> 3) Blocks that do not have a separate scope
> 4) Fall through by default
> while still keeping the design as a unified switch language feature.
>
> To tackle #1 and #2, all cases in an expression switch must start with
> arrow -> (and all in statement switch must start with colon :)
> To tackle #3, all blocks in an expression switch must have braces
> To tackle #4, disallow fall through in expression switch (or add a
> fallthrough keyword)
>
> Here is the impact on some code:
>
> Current:
>
> var action = switch (light) {
> case RED:
> log("Red found");
> break "Stop";
> case YELLOW:
> case GREEN -> "Go go go";
> default:
> log("WTF: " + light);
> throw new WtfException("Unexpected color: " + light);
> }
>
> Alternate proposal:
>
> var action = switch (light) {
> case RED -> {
> log("Red found");
> break "Stop";
> }
> case YELLOW, GREEN -> "Go go go";
> default: -> {
> log("WTF: " + light);
> throw new WtfException("Unexpected color: " + light);
> }
> }
>
> How is this still a unified switch? By observing that switch can be
> broken down into two distinct phases:
> - matching
> - action
> What makes it unified is that the matching phase is shared. Where
> statement and expression switch differ is in the action phase.
>
> The unified matching phase includes:
> - target expression to switch on
> - case null
> - constant case clauses
> - pattern matching case clauses
> - default clause
>
> The action phase of a statement switch is:
> - followed by a colon
> - have non-scoped blocks
> - fall through by default
> - can use return/continue/break
>
> The action phase of an expression switch is:
> - followed by an arrow
> - have an expression or a block (aka block-expression)
> - cannot fall through
> - cannot use return/continue/break
>
> By having a unified matching phase and a separate (but consistent)
> action phase in each form, I believe that the overall language feature
> would be much simpler to learn. And importantly, it achieves the goal
> of not deprecating or threatening the existence of the classic
> statement switch.
>
> All the key differences are in the action phase, which is clearly
> identified by arrow or colon (no remote context). Developers will come
> to associate the rule differences between the two forms with the arrow
> or colon, while the pattern matching knowledge is shared.
>
> Of course, the matching phase is not completely unified - expression
> switches must be exhaustive, and they may have auto default case
> clauses. (Perhaps the unified matching phase mental model suggests
> that auto default would be better written explicitly, eg. "default
> throw;", which could then apply to both statement and expression. Not
> sure.)
>
> I hope this alternate proposal is clear. To me, the split between a
> unified matching phase and a consistent but different action phase
> clearly identified in syntax results in much better readability,
> learning and understandability.
>
> Stephen
> PS. I think there are alternate block expression syntaxes, including
> ones that avoid "break expression", but I've chosen to avoid that
> bikeshed and use the closest one to the current proposal for the
> purpose of this mail
