[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