Next up for patterns: type patterns in switch

[Brian Goetz]

> The main drawback, being total is not a __local__ property.

This is true, and we've talked about this from the beginning, but I also 
think that the fear of nonlocality here is pretty overblown. Yes, there 
are puzzlers, but they are mostly of the kind where `var` and "diamond" 
interact -- and the solution to those puzzlers is "add back some 
explicitness, so it's clear what is going on."  The solution is not 
"let's cripple var so it doesn't interact with diamond", or "let's 
outlaw the interaction of var and diamond" or "let's not do var."

We proposed using totality not because its "clever", or because it makes 
a certain pesky problem go away, but because it is the most _natural_ 
way to unify the semantics of all the ways patterns are used, and this 
becomes obvious once you get to examples that actually use nested 
patterns.  I think much of the reaction to this aspect is based on 
holding on to the existing model of switch/instanceof, which are both 
very limited right now.  Once you see these as more general 
deconstruction operations, the role of totality immediately comes to the 
fore, because of the expanded range of problems we will see with 
conditional destructuring.  So I think there's a lot of "judging the new 
feature by the use cases of the old feature."  We may be reusing the 
syntax of instanceof and switch (for good reasons), but these are not 
the instanceof and switch you learned about in CS 101.  Lets not hobble 
the new feature because the old version was insufficiently ambitious.

> So this is far worst that re-organizing two cases in the switch because as a user you have done something. A pattern can be total or not depending if someone change the return type of the method you are switching on (this methods can be in another module) or change the class hierarchy (again, the hierarchy can be defined in another module), the code stay exactly the same but the semantics is changed.

Sorry, but I think this is mostly FUD.  There are a zillion ways to 
leave information implicit: var, diamond, generic invocation, method 
chaining, method references (which pick an overloading), implicit 
lambdas, etc.  And there are a zillion ways to construct puzzlers from 
code that does something implicit, where the answer would be obvious if 
we wrote out the fully explicit representation.  And the same thing 
always happens when a new feature wants to join this club: "There exists 
a possible way someone could get confused by combining these ten 
features, so we must blame the last feature that came in the door!"

So, coming back to the main goal, our job here is first to find the 
_natural_ semantics of pattern  matching.  And every path I've gone down 
tells me that totality is part of the natural semantics.  And I've not 
seen any credible arguments that suggest it is not -- just fear that, 
through interactions with other features, it might be too new, too 
complicated, too confusing, etc.  But this happens with every new 
feature!  We're used to (and have come to terms with) the OLD features 
interacting in possibly puzzling ways (e.g., var+diamond), but when a 
corner of a corner of a NEW feature threatens to do so, people declare 
"this entire new feature is broken."

More importantly, we want to have the right _global_ story. Proposing 
localized hacks to deal with the aspects you don't like is highly 
unlikely to bring us to the right global story.