break seen as a C archaism
lowasser at google.com
Wed Mar 14 19:38:51 UTC 2018
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
- 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.
More information about the amber-spec-observers