Nullity (was: Pattern features for next iteration)

[Maurizio Cimadamore]

On 21/01/2021 19:19, Brian Goetz wrote:
> 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.

I see - thanks for explaining. I thought for a moment that the proposal 
implied having type test patterns matching nulls, but I now realize that 
I have read too much between the lines.

Maurizio

>
> 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):
>