<div dir="ltr">Just to make sure we have some numbers when talking about fallthrough:<div><ul><li><font size="2">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.)</font></li><li><font size="2">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.</font></li></ul><div><br></div></div><div class="gmail_quote"><div dir="ltr">On Wed, Mar 14, 2018 at 11:32 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank" class="cremed">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">  - That we are
                overloading an existing control construct, "break", to
                mean something just different enough to be
                uncomfortable;<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>To some degree yes, since `break <identifier>`
              already means something.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div><div text="#000000" bgcolor="#FFFFFF">
    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.)  <br></div><div text="#000000" bgcolor="#FFFFFF">
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> 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.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div><div text="#000000" bgcolor="#FFFFFF">
    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.<br>
    <br>
    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.  <br>
  </div>

</blockquote></div></div>