[External] : Re: case null and type pattern
forax at univ-mlv.fr
forax at univ-mlv.fr
Mon Jul 19 14:01:48 UTC 2021
> 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>
More information about the amber-spec-experts
mailing list