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.go...@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. >
