> From: "Brian Goetz" <[email protected]> > To: "Remi Forax" <[email protected]> > Cc: "Gavin Bierman" <[email protected]>, "Manoj Palat" > <[email protected]>, "amber-spec-experts" > <[email protected]> > 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:[email protected] | >>> <[email protected]> ] >>> To: "Gavin Bierman" [ mailto:[email protected] | >>> <[email protected]> ] , "Manoj Palat" [ >>> mailto:[email protected] | >>> <[email protected]> ] >>> Cc: "amber-spec-experts" [ mailto:[email protected] | >>> <[email protected]> ] >>> 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:[email protected] | >>>>> <[email protected]> ] 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
