<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">We're preparing a third
        preview of type patterns in switch.  Normally we would release
        after a second preview, but (a) we're about to get record
        patterns, which may disclose additional issues with switch, so
        best to keep it open for at least another round, and (b) we're
        proposing some nontrivial changes which deserve another
        preview.  <br>
        <br>
        Here's where we are on these.  <br>
        <br>
      </font></font>
    <blockquote type="cite" cite="mid:06062579-A7DD-499C-839D-B77A319E38ED@oracle.com">
      <pre class="moz-quote-pre" wrap="">1.  Treatment of total patterns in switch / instanceof</pre>
    </blockquote>
    <br>
    Quite honestly, in hindsight, I don't know why we didn't see this
    sooner; the incremental evolution proposed here is more principled
    than where we were in the previous round; now the construct
    (instanceof, switch, etc) *always* gets first crack at enforcing its
    nullity (and exception) opinions, and *then* delegates to the
    matching semantics of the pattern if it decides to do so.  This
    fully separates pattern semantics from conditional construct
    semantics, rather than complecting them (which in turn deprived
    users of seeing the model more clearly.)  In hindsight, this is a
    no-brainer (which is why we preview things.)  We'll be addressing
    this in the 3rd preview.  <br>
    <br>
    <blockquote type="cite" cite="mid:06062579-A7DD-499C-839D-B77A319E38ED@oracle.com">
      <pre class="moz-quote-pre" wrap="">2.  Positioning of guards</pre>
    </blockquote>
    <br>
    Making guards part of switch also feels like a better factoring than
    making them part of patterns; it simplifies patterns and totality,
    and puts switch on a more equal footing with our other conditional
    constructs.  We did go back and forth a few times on this, but
    having given this a few weeks to settle, I'm pretty convinced we'd
    regret going the other way.  <br>
    <br>
    There were two sub-points here: (a) is the guard part of the pattern
    or part of switch, and (b) the syntax.  There was general agreement
    on (a), but some had preference for && on (b).  I spent some
    more time thinking about this choice, and have come down firmly on
    the `when` side of the house as a result for a number of reasons.  <br>
    <br>
     - Possibility for ambiguity.  If switching over booleans (which we
    will surely eventually be forced into), locutions like `case false
    && false` will be very confusing; it's pure puzzler
    territory.  <br>
     - && has a stronger precedence than keyword-based operators
    like `instanceof`'; we want guards to be weakest here.<br>
     - Using && will confuse users about whether it is part of
    the expression, or part of the switch statement.  If we're deciding
    it is part of the switch, this should be clear, and a `when` clause
    makes that clear.  <br>
     - There are future constructs that may take patterns, and may (or
    may not) want to express guard-like behavior, such as `let`
    statements (e.g., let .. when .. else.)  Expressing guards here with
    && is even less evocative of "guard condition" than it is
    with switches.<br>
     - Users coming from other languages will find `case...when` quite
    clear.  <br>
     - We've talked about "targetless" switches as a possible future
    feature, which express multi-way conditionals:<br>
    <br>
        switch { <br>
            case when (today() == TUESDAY): ...<br>
            case when (location() == GREENLAND): ...<br>
            ...<br>
        }<br>
    <br>
    This would look quite silly with &&.  Similarly, one could
    mix guards with a targeted switch:<br>
    <br>
        switch (x) { <br>
            case Time t: ...<br>
            case Place p: ...<br>
            default when (today() == TUESDAY): ... tuesday-specific
    default<br>
            default: ... regular default ... <br>
    <br>
    Expressing guards that are the whole condition with `when` is much
    more natural than with &&.  <br>
    <br>
    tl;dr: inventing a `when` modifier on switch now will save us from
    having to invent something else in the future; choosing &&
    will not.  <br>
    <br>
    We can continue to discuss the bikeshed at low volume (at least
    until we start repeating ourselves), but we need to address both of
    these points in the 3rd preview.  <br>
    <br>
    <blockquote type="cite" cite="mid:06062579-A7DD-499C-839D-B77A319E38ED@oracle.com">
      <pre class="moz-quote-pre" wrap="">3.  Type refinements for GADTs</pre>
    </blockquote>
    <br>
    I've been working through the details here, and there are a number
    of additional touch points where GADTs can provide type refinement,
    not just on the RHS of a case, such as totality and inference.  I'll
    be pulling all these together to try to get a total picture here. 
    It's not a blocker for the 3rd preview, it can be a future
    refinement.  <br>
    <br>
    <blockquote type="cite" cite="mid:06062579-A7DD-499C-839D-B77A319E38ED@oracle.com">
      <pre class="moz-quote-pre" wrap="">4.  Diamond for type patterns (and record patterns)
</pre>
    </blockquote>
    This seems desirable, but there are details to work out.  It's not a
    blocker for the 3rd preview, it can be a future refinement. 
  </body>
</html>