[patterns] Nullability in patterns, and pattern-aware constructs (again)

Brian Goetz brian.goetz at oracle.com
Fri Jan 10 03:04:33 UTC 2020

I guess that means the stuff I said about "only having to look in two 
places" for null-handling was wrong; any static (declared) pattern could 
be nullable.  Which brings us back to the place that people didn't like 
the last time around -- you have to scrutinize the implementations of 
the patterns associated with all N cases to determine whether this 
switch will take nulls or not.

On 1/9/2020 7:57 PM, John Rose wrote:
> We haven’t yet moved on to library-defined patterns (“static
> patterns”).  To gaze a bit into the crystal ball:  I think it’s
> likely that those will provide a way to express T? using
> a library API instead of a language primitive.  We should
> defer building out that last 1% of null support either
> indefinitely, or until there is a way for libraries to define
> their own kinds of patterns.  In the latter case the cost
> of adding a nullable pattern is likely to be lower than
> the alternatives on the table, since library changes are
> always cheaper than language changes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200109/9fdafd85/attachment-0001.htm>

More information about the amber-spec-experts mailing list