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
