Nullity (was: Pattern features for next iteration)

[Brian Goetz]

While I'll take the agreement, I must point out that we haven't ditched 
the "subtle type dependency."  We would still use totality to determine 
whether null is matched or not; what this gives us is the ability to opt 
out of matching null in those cases by saying "but not nulls, please."  
The action-at-a-distance is still there, but we can control it locally 
if we don't like it.

On 1/21/2021 2:15 PM, Maurizio Cimadamore wrote:
> This seems a very nice twist - while slightly more verbose, what we 
> get back is that patterns "say what they mean", and there's no subtle 
> type dependency analysis which determines the fate of null. This had 
> me a bit worried, since this creates an action-at-a-distance between 
> the type of the target expression and the selected semantics of a 
> match expression - which is not unlike when we have overload 
> resolution depending on the results of type inference (albeit to a 
> lesser degree).
>
> Maurizio
>
> On 21/01/2021 18:52, Brian Goetz wrote:
>> Here's what is new: the treatment of guards as composable patterns. 
>> With that, we can write a "non-nullable" nested pattern like:
>>
>>     case Foo(Object o & false(o == null)):
>>
>> or
>>
>>     case Foo(Object o) & false(o == null):

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