<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="+1"><font face="monospace">Maurizio's comment got me
        thinking about a possible way to eliminate the sharp edge of
        "sometimes switches are type-checked for exhaustiveness, and
        sometimes not."  <br>
        <br>
        Historically, there is no requirement that switches be
        exhaustive; legacy switches without a default are like
        unbalanced ifs.  (Notably, though, the DA rules do distinguish
        between switches with and without a default, and switches
        implicitly reject any null remainder -- so we still do have a
        solid base to build on here.)<br>
        <br>
        When we did expression switches, we said "expression switches
        must be total."  This was a forced move if we wanted to reuse
        "switch", because expressions must be total and compatibility
        backed us into letting statement switches be partial. 
        Unfortunately, this leaves statement switches with less type
        checking than expression switches, since there is no way to even
        opt into exhaustiveness checking.  <br>
        <br>
        As switch gets more powerful (e.g., switching over sealed types
        with patterns), this lack of exhaustiveness checking becomes a
        bigger deal.  We'd been imagining that we'd have to "patch"
        switch to allow opting into exhaustiveness checking, but maybe
        there's another way.<br>
        <br>
        As we are about to dramatically extend the power of switch (by
        permitting pattern labels, and allowing switches on other types
        than integers, boxes, strings, and enums), what we could do is:<br>
        <br>
         - Erroring on non-exhaustive non-legacy statement switches now;<br>
         - Warning on non-exhaustive legacy statement switches now;<br>
         - Later upgrading these warnings to errors, after a period of
        time where people can update their code.<br>
        <br>
        The world we end up in in the long run is: all switches are
        exhaustive, with no new language surface for managing
        exhaustiveness.  <br>
        <br>
        Legacy switches are those whose operand type is one of the
        "classic" types and all labels are constant labels or
        "default".  <br>
        <br>
        For a switch that is deliberately non-exhaustive, all the user
        has to do to capture this (and shut up the compiler) is:<br>
        <br>
            default: break;<br>
        <br>
        which is not very intrusive, and arguably makes the code more
        readable anyway.  Users will see a speed bump when upgrading to
        pattern switches (clippy will tell them "I see you're writing a
        pattern switch, don't forget to end it with default:break")
        which presumably they will quickly internalize.  <br>
        <br>
        (How's that for teaching an old dog new tricks?)<br>
        <br>
      </font></font>
  </body>
</html>