[External] : Re: case null and type pattern

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Gavin Bierman" <gavin.bierman at oracle.com>, "Manoj Palat"
> <manoj.palat at in.ibm.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Lundi 19 Juillet 2021 15:49:22
> Subject: Re: [External] : Re: case null and type pattern

> Sure, but again, I think users would find that restriction even more annoying;
> the vast majority of guards in languages with guarded patterns use the bindings
> to refine the match. I'm not sure users would thank us for moving the
> restriction in this way.
I was thinking about the binding after the ':' or '->', not the fact that the same binding is used inside a guard, 
because it's not exactly the same binding. 

Let's compare 
case String s && s != null -> 
and 
case null, String s && s != null -> 

in the second case, there is a 'merge' between null and String s, there are two questions, do we allow this kind of merge and does a merge with null a special kind of merge. 

> A more interesting flavor of the same question, though, is what happens if we
> allow _ to be used as a binding name. Then, the restriction on fall-through
> could be relaxed if we wanted; it would be safe to do:

> case Foo _, Bar _: blah

> whereas today we don't allow mixing of these patterns.
I agree, it seems we want to allow some merging (with null, with '_', are there others ??) but not the general form. 

Rémi 

> On 7/19/2021 9:09 AM, Remi Forax wrote:

>>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>> To: "Gavin Bierman" [ mailto:gavin.bierman at oracle.com |
>>> <gavin.bierman at oracle.com> ] , "Manoj Palat" [ mailto:manoj.palat at in.ibm.com |
>>> <manoj.palat at in.ibm.com> ]
>>> Cc: "amber-spec-experts" [ mailto:amber-spec-experts at openjdk.java.net |
>>> <amber-spec-experts at openjdk.java.net> ]
>>> Sent: Lundi 19 Juillet 2021 15:00:16
>>> Subject: Re: case null and type pattern

>>> Right. In theory, we could allow guarded patterns here, but they will be hard to
>>> use, since users will likely want to use the binding in the guard, and would
>>> have to check for nullity every time.
>> As you said, the error is to be able to use the binding not to be able to
>> express that pattern.

>> Rémi

>>> On 7/19/2021 6:16 AM, Gavin Bierman wrote:

>>>> Hi Manoj,

>>>> This is certainly something we can discuss for Preview 2, but…it is intentional
>>>> for now. The `case null, T t` is really a special case of extending a type
>>>> pattern to be null friendly. Remember that the pattern variable `t` is
>>>> initialised with null if this case label applies.

>>>> The problem with what you are suggesting is that we’re going to end up with code
>>>> like:

>>>> switch(o) {
>>>>     …
>>>>     case null, String s && s != null -> …
>>>> }

>>>> Now the developer has a guard saying that `s` is not null, and is probably going
>>>> to assume this in the body of the switch rule, but has erroneously extended the
>>>> case label with null.

>>>> So, it’s just an attempt to remove potential puzzlers by design. But we can take
>>>> a look at whether we can capture a more generous definition. An alternative
>>>> would be to define a new null-friendly type pattern. Let’s talk about it!

>>>> Thanks,
>>>> Gavin

>>>>> On 14 Jul 2021, at 23:43, Manoj Palat [ mailto:manoj.palat at in.ibm.com |
>>>>> <manoj.palat at in.ibm.com> ] wrote:

>>>>> Hi Gavin, All,

>>>>> In [
>>>>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.30.1
>>>>> |
>>>>> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.30.1
>>>>> ] , Section 14.11, I see "If a switch label has a null case label element then
>>>>> if the switch label also has any pattern case element labels, they must be type
>>>>> patterns (14.30.1)." implying that the following code:

>>>>> private static void foo(Object o) {
>>>>> switch (o) {
>>>>> case null, Integer i && i > 10 -> System.out.println(0); // flag error?
>>>>> default -> System.out.println(o);
>>>>> }
>>>>> should have an error flagged for case label with null since the pattern case
>>>>> label element is not a type pattern but a guarded pattern.
>>>>> Any reason for excluding guarded patterns here? Or does this requires a
>>>>> modification in spec to include guarded patterns as well?

>>>>> Regards,
>>>>> Manoj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210719/a2d8359a/attachment.htm>