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

[Guy Steele]

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>