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.
