<div dir="ltr">I was proposing `default, case null` above, in order to keep `default` parallel with `case` instead of appearing like it can be subordinate to it. Put another way `case null, default` looks like you can remove the `null, ` from it, just as you could in other labels.<div><br></div><div>However, once that's allowed, then people would automatically try `case null, default` anyway. Whichever way we wanted, they would try both ways.</div><div><br></div><div>This small mess constitutes one of the valid arguments (to me) for delaying this sad change as long as possible. :-)  However, I admit I still need to make progress understanding exactly how big the <i>upside</i> is in the world of patterns. You've explained it patiently a few times and I probably just need to reread it.</div><div><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 20, 2018 at 11:40 AM, Brian Goetz <span dir="ltr"><<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <tt>One thing that is relevant to the short term is that now that we
      killed mixed labels, we'd have to have a way to say "case null or
      default" in arrow world.  The least stupid thing seems to be to
      allow default to be tacked on to a comma-separated case list as if
      it were a pattern: <br>
      <br>
          case A -> s1;<br>
          case null, default -> s2;<br>
      <br>
      since you can no longer say:<br>
      <br>
          case A -> s1;<br>
          case null:<br>
          default:<br>
              s2;<br>
      <br>
      <br>
    </tt><div><div class="m_3689040982863325814h5">
    <div class="m_3689040982863325814m_5369727903296403943moz-cite-prefix">On 4/20/2018 2:36 PM, Kevin Bourrillion
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Fri, Apr 20, 2018 at 10:45 AM,
            Brian Goetz <span dir="ltr"><<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>></span>
            wrote:</div>
          <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"><span>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div class="gmail_extra">
                        <div class="gmail_quote">
                          <div>So, all I'm asking is: can we make this
                            particular change atomically with patterns
                            itself, not before? I believe that the
                            change has negative value until then because
                            it is too easy to use it to write bugs. (If
                            this means that <font face="monospace,
                              monospace">long</font><span style="font-family:arial,sans-serif;color:rgb(34,34,34);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"> and
                            </span><span style="color:rgb(34,34,34);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"><font face="monospace, monospace">boolean</font></span><span style="font-family:arial,sans-serif;color:rgb(34,34,34);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">
                              also wait until then, I don't think anyone
                              would really mind. If necessary I can look
                              up how common simulated-switch-on-</span><span style="color:rgb(34,34,34);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"><font face="monospace, monospace">long</font></span><span style="font-family:arial,sans-serif;color:rgb(34,34,34);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">
                              happens in our codebase, but we all know
                              it won't be much.)</span></div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span>The extra primitive types are separable, so could
                be deferred.  I'd be less sanguine about adding long now
                but not float.  <br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Agreed, it would seem weird to keep adding more
              piecemeal over and over.</div>
            <div><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"><span>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div class="gmail_extra">
                        <div class="gmail_quote">Separately but
                          similarly, the merits of <font face="monospace, monospace">case null:</font>
                          have also been justified almost entirely in
                          the context of patterns. Without patterns, I
                          believe the benefits are far too slight. We
                          studied six digits' worth of switch statements
                          in the Google codebase, using a <i>liberal</i>
                          interpretation of whether they are simulating
                          a null case, and came up with ... 2.4%.  (You
                          will find that suspicious as hell, since it's
                          the exact same percentage I cited for
                          fall-through yesterday, but I swear it's a
                          coincidence!)</div>
                      </div>
                    </div>
                  </blockquote>
                </span>More nervous about this.  Would rather start the
                education curve on this earlier. And there are plenty of
                existing switches that are wrapped with "if target !=
                null" that would be clearer/have less needless
                repetition by pushing the case null into the switch. <br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Er - just clarifying that this is the <i>same</i> 2.4%
              that I am referring to. Of course, numbers will vary (and
              I concede that we are quite toward the null-hostile end of
              the spectrum in our general dev practices). Still, I'm
              sure we would not be making this change for this reason
              alone, so it really is about this issue of "starting the
              education curve earlier". Trying to figure out how much
              that matters.</div>
            <div><br>
            </div>
            <div>For what it's worth, Guava took the position at the
              start that, since working with null is risky and
              problematic, it's <i>okay</i> if code that deals with
              null is uglier than code that doesn't. It's only natural,
              so we don't bend over backwards to try to smooth it over.
              If that decision has played <i>some</i> <i>small</i> part
              in helping shift the world away from rampant overuse of
              null everywhere, we wouldn't regret it a bit. I think JDK
              collections post-1.4 could say the same thing to a larger
              degree. Okay, I guess this is just the "moral hazard"
              argument stated a different way - sorry.</div>
          </div>
          <div><br>
          </div>
          <div>(Full disclosure: if you accuse me of wanting more time
            before `case null:` lands just so I have more time to try to
            talk us out of it completely, I suppose have no defense to
            that. :-))</div>
          <div><br>
          </div>
          --<br>
          <div class="m_3689040982863325814m_5369727903296403943gmail_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>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_3689040982863325814gmail_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></div>