[patterns] on treatment of null
Brian Goetz
brian.goetz at oracle.com
Fri Jul 28 13:03:12 UTC 2017
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.
>
More information about the amber-spec-experts
mailing list