JEP325: Switch expressions spec
kevinb at google.com
Mon Apr 23 20:22:24 UTC 2018
On Mon, Apr 23, 2018 at 12:00 PM, Guy Steele <guy.steele at oracle.com> wrote:
> On Apr 23, 2018, at 2:58 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> On Mon, Apr 23, 2018 at 11:20 AM, Guy Steele <guy.steele at oracle.com>
> (1) We have moved toward allowing “arrow versus colon” to be a syntax
>> choice that is COMPLETELY orthogonal to other choices about the use of
>> `switch`. If this rule is to hold universally, then any switch statement
>> or expression should be convertible between the arrow form and the colon
>> form using a simple, uniform rule.
>> (2) In switch expressions we want to be able to use the concise notation
>> `case a, b, c -> s;` for a switch clause.
>> (3) From (1) and (2) we inexorably conclude that `case a, b, c: break s;`
>> must also be a valid syntax.
>> (4) But we could also have written (3) as `case a: case b: case c: break
>> s;` and we certainly expect them to have equivalent behavior.
>> (5) From (1) and (4) we conclude that we ought also be to be able to
>> write `case a -> case b -> case c -> s;`.
> Not necessarily, if one simply views (4) as being an artifact of colonform
> switch's capacity for fall-through, which we know should not carry over.
> (Although we technically don't use the term "fall-through" in this
> no-intervening-code case, it works the same way and many people do think of
> it that way.)
> You could view it that way—but such a view is incorrect, going back to
To be more clear, I wasn't trying to make a statement about what is correct
or incorrect by the spec. (On such matters I will always be deferring to
the rest of you!)
My claim is just that it is not hard for a user to make sense of why `case
A: case B: x` would work in colonform yet `case A -> case B -> x` might not
work in arrowform. These don't necessarily feel contradictory. A user may
simply understand that since colonform's design is made to support
fall-through, that became an obvious way that *it* could address multiple
labels as well, whereas the same does not apply in arrowform.
Okay, so it's a "folk model". I think that neither makes it automatically
good nor automatically bad.
To the user, I believe that the ability to choose `case A -> case B ->` is
an unnecessary choice and feels like the same kind of baggage that I'd
hoped to leave behind when moving to arrowform.
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
More information about the amber-spec-observers