case null and type pattern

Gavin Bierman gavin.bierman at oracle.com
Mon Jul 19 10:16:11 UTC 2021


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 <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, 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



More information about the amber-spec-experts mailing list