[External] : Re: Switch labels (null again), some tweaking

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "John Rose" <john.r.rose at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 23 Avril 2021 22:38:41
> Objet: Re: [External] : Re: Switch labels (null again), some tweaking

> On 4/23/2021 4:25 PM, Remi Forax wrote:

>>> Bottom line:  Trust the users to choose how
>>> explicit to be with nulls.  More importantly,
>>> trust them with compositional notations.

>> That's a solution, we do nothing and trust users.
>> The other solution is to force users to explicit say that the pattern is total,
>> by example by asking to use 'var o' instead of 'Object o',
>> but we already discuss that and only me and Tagir were agreeing that it is a
>> good idea.

> Yes, this is what I meant by "move the distinction around." We could say that
> `var x` and `Object x` are different patterns; this is a sharp edge in one
> place (blows up the notion that `var` is just type inference.) We could say
> that `default` and `Object x` are different patterns (which is what I'm
> suggesting), which puts the sharp edge somewhere else -- it means that people's
> notion of totality is polluted by historical chance. We could have different
> patterns for Object! and Object?, which is appealing in a "say what you mean"
> way, but which forces users to think about a corner case all the time.
For the record, I was proposing to disallow `Object o` as a total pattern (as we disallow instanceof Object o) instead of making `var x` and `Object x` two different patterns, 
well, it also can be seen as two different patterns with `Object o` being an invalid one. 

> Reasonable people can differ about which of these (or other) approach is best
> for Java, but it is not reasonable to believe that we can hide this
> distinction.

Yes ! 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210423/ad502553/attachment.htm>