On Tue, Mar 13, 2018 at 2:21 PM John Rose <john.r.r...@oracle.com> wrote:

(Or is "fallthrough" the phenomenon where several case labels converge
> to one statement?  I am doubtful that is what you mean because it seems
> expression switches are very likely to need to reply to several target
> values with one expression, just as with statement switches.)

Nope, I just consider that to be multiple labels on a statement group, as
implied by JLS 14.11.

C is a tautology, so I'm not sure what it tells us.  Are you saying that
> order-invariance is an important property for expressions but not
> statements?

Yeah, it follows from the absence of fall-through, and I retract listing
it. :-) I was just in the mode of noting various ways we like that
expression switches are simple.

> D is an extension of A, upgrading the branch-free property to the
> absence of all side effects, making s-switches like lambdas.  I do
> *not* think this is a realistic goal, not even for a highly disciplined
> shop like Google.

I have no illusions of preventing side effects. I simply don't place much
value on those use cases when evaluating usability of the feature. This was
really more relevant to my other thread.

The way I see it, D is undesirable, A is necessary to the physics
> of expressions but doesn't tell us anything about the nature of
> e-switch, and B and C apply to both kinds of switches.  So
> there's nothing here that teaches us to treat e-switch as
> something with its own special mission defined by its limitations.

I think "B and C apply to both" is an oversimplification for both B and C.
Only expression switches are exhaustive (whether via default or not) by
their very nature. And case order matters when fall-through can exist.

However, even if this argument is entirely valid, it still seems to be more
relevant to a scenario where we get to design "both kinds" of switch at
once in a brand new language. The fact that procedural switch has already
been around 20+ years is the major reason why I'm advocating that we leave
it alone.

> Instead, I very much believe in Brian's design heuristic of
> running a refactoring exercise over switch use cases, to make
> sure that there is (when possible) an easy transition between
> s-switch and e-switch.

I would add "for the subset of switch statements that we consider to be
expression-shaped", but maybe this is where we have some disagreement?

Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com

Reply via email to