Next up for patterns: type patterns in switch

[Brian Goetz]

> - i don't think that framing the problem we have in term of null 
> haters / null friends is productive.

It may not be productive, but it is one of the elephants in the room.  
Some people sometimes take a hostile view of null ("We should prevent 
stream elements from being null!"), and, while this is often motivated 
by the best of intentions, it is a bias we need to be aware of.

> - match :: (Pattern t) u -> Maybe t, the railway design pattern as 
> coined by Scott Wlaschin[1],  means that __each__ matcher is able to 
> decide what to do with null, so it's a more lax model as the one we 
> are working on.

Seems like exactly the model we are working on.  Some patterns can match 
null (total type patterns, any patterns, null constant pattern) and some 
cannot (deconstruction patterns, non-null constant patterns.)  
Eventually, there will be a way to write patterns in Java code (e.g., 
deconstruction patterns for arbitrary classes), but we can still make 
the "null OK / null not OK" decision for these entire categories at 
once, so humans and compilers can reason about them.

> There is a way to see a switch as a cascade of instanceof and to allow 
> null,

Herein lies danger, as both `switch` and `instanceof` have pre-existing, 
somewhat accidental null opinions.  But I agree that it is a good goal 
that switches and if-else chains of instanceof tests on the same target 
be refactorable to each other to the extent possible.

> This is almost the same semantics as the one you are proposing but 
> instead of the notion of totality, being the last case is enough to 
> accept null.

... but what if the switch isn't total?  I can have

     switch (o) {
         case Integer i: ...
         case String s: ...
         // no default, no total pattern
     }

and it would be quite surprising to randomly shove nulls into the last 
case.  This would prevent the cases from being reordered even though 
they have no dominance ordering.  The reason the last case is special in 
the examples we've given so far is ... wait for it ... THEY ARE TOTAL.  
It would be a compiler error to have any more cases after them.  They 
are intrinsically catch-alls.

> I prefer this semantics, because it's local, the last case allows 
> null, it doesn't depends on the type of v or the relationship between 
> A and B.

This proposal seems entirely motivated by "let's have a really simple 
rule", rather than based on principles of what actually should happen in 
real programs or what programs should be expressible.  And, regardless 
of motivation, it is surely the wrong answer.