[patterns] on treatment of null

[Brian Goetz]

After thinking over the options, I think #4 is the sensible direction.  
Not having

     case Foo(var x)
or
     case Foo(Integer x)

match Foo(null) seems a non-starter (#1); the "type-restatement" 
approach seems too subtle (#2), and having

     if (x matches Foo f)

match null (#3) seems like bug-bait.

The concern over #4 is a mostly theoretical one; that we wanted the 
nested pattern

     P(Q)

to be equivalent to

     P(var x) && x matches Q

and we were concerned that special treatment of some patterns in nested 
contexts would be complex.  But, I don't think its that bad.  If we 
define an operator on patterns N(P) where:

     N(P) = null || P   // where P is a type-test pattern
     N(P) = P           // otherwise

Then, we define

     P(Q) == P(var x) && x matches N(Q)

to address the irregularity.




On 7/7/2017 8:56 AM, Maurizio Cimadamore wrote:
> Hi,
> over the last few weeks we've been exploring the twisted relationship 
> between patterns and nulls. This document:
>
> http://cr.openjdk.java.net/~mcimadamore/nulls-patterns.html
>
> provides some (hopefully helpful) insights into what the design space 
> looks like.
>
> tl;dr;
>
> Looks like trying to force the same rule on all patterns, regardless 
> of where they appear, leads to problems. Distinguishing between 
> toplevel and nested patterns provides a good basis to handle null in a 
> more predictable/flexible fashion.
>