The problem: if there is no explicit "case null", the spec relies on the last case being total or not to accept null.
The idea that relying only on the last case being total or not is a bad idea, because 1/ the syntax for a total case and a non total case are exactly the same while the semantics is not. 2/ knowing if something is total for a human is not obvious 3/ being total is not a local property. The proposed solution is necessarily "just a fix" because it's the only part of the spec that bug me. So i've unsuccessfully proposed several ways to make explicit that the case is total. First, using a special syntax to declare that a case is total, "case var|null" or "case any", or whatever syntax you find cool. Then i've proposed that the last case is always total because it's always like a cast and not like an instanceof. I'm now proposing to disallow the use of an explicit type in a total pattern and to ask users to use "case var" instead which is a restriction on the current proposed semantics. Using "case var" make it obvious that the pattern is total, it's syntactically different from the other case and it is a local property because the type is inferred as the same as the type switched upon (so even if the type switched upon changed, the case stay total). Rémi
