break seen as a C archaism

[Louis Wasserman]

Just to make sure we have some numbers when talking about fallthrough:

   - Among all switches, we calculate that 2.4% of switches in the Google
   codebase have some nontrivial fallthrough.  (This is possibly an
   overestimate due to overly conservative control flow analysis, but not an
   underestimate.)
   - Determining whether switches with nontrivial fallthrough are
   convertible to expression switches is a little difficult in terms of
   control flow analysis.  As the best proxy with the dataset I already
   scraped,  I defined "convertible to expression switch" as "switches in
   which all cases *that provably exit* either return, or assign to the same
   variable", and among those, 1.2% of switches have nontrivial fallthrough.


On Wed, Mar 14, 2018 at 11:32 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
>  - That we are overloading an existing control construct, "break", to mean
>> something just different enough to be uncomfortable;
>>
>
> To some degree yes, since `break <identifier>` already means something.
>
>
> Digging deeper: If we spelled "break <value>" differently (yield, emit,
> defuse), would it be significantly different?  I think reusing "return" is
> worse than reusing "break", but there are other choices.  (Though
> introducing a new keyword has its own user-model challenges.)
>
>  Part of it is that I know how to make sense of (a) current switch and (b)
> a simple well-behaved nice expression switch that only uses `->`, but
> knowing that I may have to deal with (c) code that is some mixture between
> the two feels like additional level of complexity to me. Even if from an
> implementation standpoint it's not.
>
>
> I like to think that this is pedagogical, stemming from thinking of switch
> expressions and switch statements as unrelated things.  If we view
> expression switches as a generalization of existing switch, I think that
> the dichotomy between A/B can go away.  But only if there is a clear enough
> explanation that everyone will eventually receive.
>
> C is still an issue, and I do get the discomfort of mixing both -> and :
> cases, and I agree that good style will minimize mixing.  Outlawing mixing
> entirely isn't a great answer, though; its too common to use -> for all the
> cases except default, which often needs statements to do its thing.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180314/8b97ee7f/attachment.html>