<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 9, 2018 at 3:21 PM, Louis Wasserman <span dir="ltr"><<a href="mailto:lowasser@google.com" target="_blank">lowasser@google.com</a>></span> wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Simplifying: let's call normal cases in a switch simple if they're a single statement or a no-op fallthrough, and let's call a default simple if it's a single statement or it's not there at all.<div><br></div><div>Among switches apparently convertible to expression switches,<br><div><ul><li><font size="2">81% had all simple normal cases and a simple default.</font></li><li><font size="2">5% had all simple normal cases and a nonsimple default.</font></li><li><font size="2">12% had a nonsimple normal case and a simple default.</font></li><li><font size="2">2% had a nonsimple normal case and a nonsimple default.</font></li></ul><div><font size="2"></font></div></div></div></div></blockquote><div>I was surprised it was as high as 19%, so I grabbed a random sample of these 45 occurrences from Google's codebase and reviewed them. My goal was to find evidence that multi-statement cases in expression switches are important and common. Spoiler: I found said evidence underwhelming.</div><div><br></div><div>There were 3 that I would call false matches (e.g. two that simply used a void `return` instead of `break` after every case without reason).</div><div><br></div><div>There were fully 20 out of the remaining 42 that I quickly concluded should be refactored regardless of anything else, and where that refactoring happens to leave them with only simple cases and simple/no default. These refactorings were varied (hoist out code common to all non-exception cases; simplify unreachable code; change to `if` if only 1-2 cases; extract a method (needing only 1-2 parameters) for a case that is much bigger than the others; switch from loop to Streams; change `if/else` to ?:; move a precondition check to a more appropriate location; and a few other varied cleanups).</div><div><br></div><div>Next there were 7 examples where the non-simple cases included side-effecting code, like setting fields or calling void methods. In Google Style I expect that we will probably forbid (or at least strongly dissuade) side effects in expression switch. I should probably bring this up separately, but I am pretty convinced by now that users should see expression switch and procedural switch as two completely different things, and by convention should always keep the former purely functional.<br></div><div><br></div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Next there were 7 examples where a case was "non-simple" only because it was using the "log, then return a null object (or null), instead of throwing an exception" anti-pattern. I was surprised this was that popular. and another 2 that used the "log-and-also-throw" anti-pattern.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div>2 examples had a use-once local variable that saved a <i>little</i> bit of nesting. I wouldn't normally refactor these, but if expression switch had no mechanism for multi-statement cases, I wouldn't think twice about it.</div><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">1 example had cases that looked nearly identical, 3 statements each, that could all be hoisted out of the switch, except that the types that differed across the three didn't implement a common interface (as they clearly should have). Slightly compelling.</span><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div>1 example had all simple cases except that one also wanted to check an assertion. Okay, slightly compelling.<br></div><div><br></div><div>Finally, the cases that were the most compelling to me: 3 examples had one or more large cases, where factoring them out into helper methods would imho be ugly because >=3 parameters would be required. If expression switch didn't permit multi-statement cases, I would just keep them as procedural switches. It's only 3 out of 42.</div><div><br></div><div>Summary:</div><div><br></div><div>imho, early signs suggest that the grossness of `break x` is not <i>nearly</i> justified by the actual observed positive value of supporting multi-statement cases in expression switch. Are we open to killing that, or would we be if I produced more and clearer evidence?</div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 9, 2018 at 2:56 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">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">
    <tt>Did you happen to calculate what percentage was _not_ the
      "default" case?  I would expect that to be a considerable
      fraction.  </tt><br></div><div text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="m_417813047818011507m_6613500527998856350moz-cite-prefix">On 3/9/2018 5:49 PM, Kevin Bourrillion
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Fri, Mar 9, 2018 at 1:19 PM, Remi
            Forax <span dir="ltr"><<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>></span>
            wrote:</div>
          <div class="gmail_quote"><br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When i
              asked what we should do instead, the answer is either:<br>
                1/ we should not allow block of codes in the expression
              switch but only expression<br>
                2/ that we should use the lambda syntax with return,
              even if the semantics is different from the lambda
              semantics.<br>
              <br>
              I do not like (1) because i think the expression switch
              will become useless</blockquote>
            <div><br>
            </div>
            <div>In our (large) codebase, +Louis determined that, among
              switch statements that appear translatable to expression
              switch, 13.8% of them seem to require at least one
              multi-statement case.</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div>
</div></div>