switch: using an expicit type as total is dangerous

[Brian Goetz]

> 2/ using an explicit type for a total type is a footgun because the semantics will change if the hierarchy or the return type of a method switched upon change.

Sorry, I think this argument is a pure red herring.   I get why this is 
one of those "scary the first time you see it" issues, but I think the 
fear has been overblown to near-panic proportions.  We've spent a lot of 
time talking about it and, the more we talk, the less worried I am.

The conditions that have to combine for this to happen are already 
individually rare:
     - a hierarchy change, combined with
     - enough use-site type inference that is not obvious what the type 
dependencies are, combined with
     - null actually being a member of the domain, combined with
     - users not realizing null is a member of the domain.

Then, for it to actually be a problem, not only do all of the above have 
to happen, but an unhandled null has to actually show up.

Even then, the severity of this case is low -- most likely, the NPE gets 
moved from one place to another.

Even then, the remediation cost is trivial.

So by the above, this seems like a corner^7 case.  How much are you 
willing to distort the language to avoid it?  I think the rational 
answer is "none".  And we've spilled a *lot* of ink on this issue -- to 
the point where it has distracted us from much  bigger concerns -- and 
the only thing you've managed to convince me of is that, the more you 
look at the issue, the more it becomes obvious that there is only one 
reasonable choice here.  So unless you have a powerful NEW argument 
other than "something could change under subtle conditions, and then 
something bad might happen", I think its time to move on.

> I believe that before talking about 1/, we should determine if we should tackle 2/ or not.

I thought we had already established this, on both counts :)

To (2), I think the semantics proposed are right.  The answer to "I can 
write code that is brittle because it depends on the type hierarchy" is 
not to forgo hierarchy analysis.

To (1), I think it treats something whose importance is "x" by spending 
1000x worth of user-model complexity budget to arrive at less sensible 
semantics.

If you have new arguments, I'm willing to hear them.  But I don't think 
there's any point in repeating the same arguments.