Next up for patterns: type patterns in switch

[Brian Goetz]

> It's not FUD, and worst you know that there is a solution to avoid the problems of non locality of requiring the last case to be total.

It's not FUD in the sense that it is something to be aware of and 
evaluate.  But it is FUD in the sense that you are presenting these 
examples as being SO CATASTROPHICALLY BAD that you are ready to pull the 
emergency brake cord on the path we've been converging on for three 
years, as if some fatal flaw was just discovered last week.

So, let's please dial down the volume, because nothing is remotely as 
bad as is being claimed.  And the local tweaks suggested so far are 
neither local nor grounded in principle nor an improvement.

> This is how i see the future if we introduce the current proposed semantics.

It could play out this way, but this feels like largely speculation.  
Speculation is of course part of our analysis toolbox, but let's not 
give it too much credit that we're willing to redesign the language over 
it.

> So i propose to disallow that a case with a total pattern can use an explicit type with a nice message saying to use "case var" instead.

OK, that's a new "solution" (which surely leads to its own problems), 
but can we please agree on an underlying problem first? (I think the 
problem you are alluding to is that it is too hard to tell whether a 
case is total?)  And can we please stop proposing "patches" until we are 
in full agreement on the problem, since it doesn't seem to be working.

> yes, we are spending a lot of time one a corner of a corner case, and i agree that totality is part of the natural semantics,
> but it doesn't mean we have to force users to think in term of totality.

That's part of the problem -- I don't remotely think we are forcing 
users to think in this terms!  I think 99.999% of the time, the obvious 
code will do the obvious thing, without forcing the users into fully 
internalizing it.