Observation about nulls in type patterns

[Brian Goetz]

> When you have a design issue where half of the planet think one way 
> and half of the planet think the other way,
> the best is to have a kind of "mother may i" rule, basically, you ask 
> the user to explicitly refine its intent.

But I don't think it is half and half.  If you show people

     switch (o) {
         case Foo(var x, var y, var z): ...
     }

and ask them "will this match all Foos", 999 out of 1000 will say "of 
course, what else could it do?"   THe idea that this might fail if z 
happened to be null would not occur to anyone.

The semantics we've proposed stem from the above observation, plus the 
requirement that `var` mean type inference, and not something more 
subtle.  If you are saying `var`, you should be able to substitute it 
for the sensibly inferred type (if it is denotable) and get the same 
semantics.  This is not a random "gee, maybe this works."

Where things are troubling are not the pattern semantics, but how it 
interacts with `switch`.  So, if you think the status quo is 
unacceptable, any "fix" needs to be closer to the switch interaction.