Feedback on nulls in switch

[Brian Goetz]

> Lets agree to disagree on tackling nulls in Java. Lets also say that
> I'm willing to accept that there is nothing I can do at this point to
> stop nulls flowing through pattern matching to some degree. Most of my
> email (the part that was snipped) was feedback on how the pattern
> `Object o` simply has no business matching null

You state that with great confidence, but I suspect you've written 
approximately zero lines of code deconstructing objects with pattern 
matching.  I think after you write a few thousand such lines, you might 
have a different perspective (or, maybe you won't, if you have a 
strongly null-averse style, in which case you won't notice the difference.)

The "type patterns should be instanceof" is a good example of a 
compelling but naive first intuition.  I know that because I was 
compelled by it when I first started thinking about the problem. Then I 
thought about it for a few hundred more hours, and realized the problem 
was more subtle than that, and that the simple-seeming solutions merely 
moved the complexity where it was more likely to startle us.

> (however clever or consistent that seems at the theoretical level).

Yes, I caught the pejorative use of 'clever' the first time, you didn't 
have to repeat it :)  But actually, its good you bring it up, because it 
illustrates how hard it can be to try to get a full picture of our 
motivation from reading the EG correspondence.  The EG mails do not 
present the model the way Effective Java would to someone who hasn't 
used the feature before; the EG discussions have a different role, which 
includes ensuring that all the corner cases have been thought through 
before we try to write the motivational story.  Consequently, they often 
appear to disproportionately focus on thorny corner cases, which makes 
it all too easy for casual readers to think that these things loom 
larger in the design rationale than they do.

> we are being asked to accept that c and f are non-null and o is
> nullable. This simply makes no sense. The pattern `Object o` should
> have the same meaning wherever it appears, and that meaning is "is it
> an instanceof Object" (and null is not an instanceof Object).

And it does.  What you're missing is that _constructs_ that are pattern 
aware may get their own first crack at the object before they try to 
match the pattern.  And this has to be true, because `instanceof` and 
`switch` do different things on null (the former rejects it silently, 
the latter loudly.)

You are trying to make the current behavior of `instanceof T` the 
handed-down-from-the-mountain-not-to-be-questioned-by-mortals-absolute-truth, 
and I understand why this is tempting, and in the first few hours of 
thinking about the problem, this seems the "obvious" and perhaps only 
possible semantics.  But this is not the primitive you are looking for.

Whether a pattern matches a target or not can be modeled like:

     interface Pattern<T,D> {
         Optional<D> match(T t);
     }

The behavior of a pattern is intrinsic to the pattern.  The meaning of 
`instanceof P` is:

     x instanceof P == (x != null) && P.match(x).isPresent()

The difference between this model and yours is that patterns and 
constructs both have their own opinions, and the result is a composition 
of the two.  (This is already true; we just have to admit it, and if we 
don't, we get a distortion elsewhere.)

Stepping back, what you're saying is that Java developers are going to 
come to the table with assumptions that pattern matching semantics will 
be derived slavishly from instanceof, and I agree that this is a risk.  
But it does not mean that this is the only option.

> If a developer uses an explicit type in a pattern
> they should get back a non-null instance of that type. Because that is
> what they explicitly asked for. End of.

I understand why you would like it to be this simple, I really do. And, 
if our plans were that pattern matching is just some optional frosting 
for eliding casts, and we were going to stop there, this might be a fine 
"worse is better" solution.  But our plans for pattern matching run much 
deeper than that, and it needs a rock-solid foundation if we're going to 
build anything on top of this.