On Apr 19, 2018, at 1:44 PM, Brian Goetz <brian.go...@oracle.com> wrote:
>
> The result is one switch construct, with modern and legacy flavors, which
> supports either expressions or statements.
+10
Incrementally improving existing constructs is better, in this case (and
usually) than piecemeal adding new-but-similar constructs to fill gaps.
More subtly, I prefer more, smaller, independently exercisable syntax
options, instead of fewer "omnibus" choices—a sushi menu instead
of a chef's choice prix fixe menu with only a few low-information decisions.
That tilts me towards {arrow,colon}x{expr,stmt} instead of a {arrow+expr,
colon+stmt}, or {switch, match}.
The choice not to mix arrow and colon, while more of a chef's-choice
move, is OK with me; I see how requiring consistent colons or the
arrows will help make switches more readable even if they grow large.
It's important to disallow both fall-in and fall-out for arrow cases,
so you can ignore the code immediately before an arrow case, and
immediately after its statement.
I anticipate "switching" to arrows as the preferred format for all of my
switches, except for the small minority which for some odd reason
need the very special expressiveness that comes from fallthrough.
— John
