[patterns] Nullability in patterns, and pattern-aware constructs (again)
Guy Steele
guy.steele at oracle.com
Fri Jan 10 03:39:39 UTC 2020
Rats! I was hoping this approach would pan out.
Oh, well. We can always use
Box box;
switch? (box) {
case Box(Chocolate c):
case Box(Frog f):
case Box(var o):
}
:-)
> On Jan 9, 2020, at 10:04 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> 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/a8df31c1/attachment.htm>
More information about the amber-spec-experts
mailing list