> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Gavin Bierman" <gavin.bier...@oracle.com>, "Manoj Palat" > <manoj.pa...@in.ibm.com>, "amber-spec-experts" > <amber-spec-experts@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.go...@oracle.com | >>> <brian.go...@oracle.com> ] >>> To: "Gavin Bierman" [ mailto:gavin.bier...@oracle.com | >>> <gavin.bier...@oracle.com> ] , "Manoj Palat" [ >>> mailto:manoj.pa...@in.ibm.com | >>> <manoj.pa...@in.ibm.com> ] >>> Cc: "amber-spec-experts" [ mailto:amber-spec-experts@openjdk.java.net | >>> <amber-spec-experts@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.pa...@in.ibm.com | >>>>> <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
