[switch] Further unification on switch

Kevin Bourrillion kevinb at google.com
Tue Apr 24 21:59:29 UTC 2018

(Moving a reply from -observers to -experts where I'd meant it to be; and
then correcting it because it was wrong. This isn't a key point of debate
though, so apologies for the nuisance.)

On Fri, Apr 20, 2018 at 7:15 AM, Kevin Bourrillion <kevinb at google.com>

> On Fri, Apr 20, 2018 at 4:09 AM, Victor Nazarov <asviraspossible at gmail.com
> > wrote:
> This proposal seems alright. But isn't it a division instead of a
>> unification?
>> The main argument against new shiny match expression was that is will
>> exists in parallel with old rusty switch statement.
>> Instead the decision was to enhance switch statement to cover use cases of
>> match expression.
>> With last proposal what we get is: old rusty familiar switch
>> statement/expression and new shiny arrow-switch statement/expression?
>> I see it as the same division that we tried to avoid: two similar, but not
>> quite the same syntax-forms.
> Well, at least they are only different on the *inside*. Whenever looking
> at one from the outside, it is still the same black box. (Actually two
> black boxes, but *that* split is expression vs. statement.) That's
> something we wouldn't have with `match` or a new operator, and that's
> something.
> Here's a fun statistic from Google's codebase. We analyzed every
> hand-written switch statement in our depot. Only *2.4%* of them used
> fall-through. The number in the real world might be somewhat higher (?),
> but we know it to be quite small. Yet, the things about switch that have
> been weird, confusing, or dangerous all stem from that fall-through model
> that such a tiny fraction need -- how sad!

We were accidentally including switch statements that had only omitted
`break` on the final statement group. The new number is 1.2%. It also
appears that very roughly one-third of these are getting such trivial
benefit from fall-through that they could *still* change to arrowform
pretty happily anyway.

These stats are mostly just useful for confirming that, yes, there is real
positive value in this feature.

> I think the highest order bit in this discussion, by far, is that we have
> found a way to make >95% of all switch statements a lot easier to write and
> read. So, *even if* some of us see this as us doing exactly what Brian
> said we shouldn't (in his "What we're not going to do") section, I *still* think
> it easily clears the bar and will be a very successful change.

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com

More information about the amber-spec-observers mailing list