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.
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.
On 7/19/2021 9:09 AM, Remi Forax wrote:
*From: *"Brian Goetz"
*To: *"Gavin Bierman" , "Manoj Palat"
*Cc: *"amber-spec-experts"
*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
wrote:
Hi Gavin, All,
Inhttp://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
Re: case null and type pattern
> From: "Brian Goetz"
> To: "Gavin Bierman" , "Manoj Palat"
>
> Cc: "amber-spec-experts"
> 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.pa...@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
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.
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 wrote:
Hi Gavin, All,
In
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
Re: case null and type pattern
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 wrote:
>
> Hi Gavin, All,
>
> In
> 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
