I am having trouble understanding the purpose of Unconditional Patterns

[Bögershausen, Merlin]

Hi,
I can confirm this for Eclipse Adoptium 19.0.1+10 and Eclipse Adoptium 17.0.5+8 on MacOS with your code.
I am with you that it looks strange as since JEP 394 [1] instance of Pattern is a permanent features and input instanceof Triple t seems like such. But the error message points us to UnconditionalPatterns and in my case to the subtype Triple and Triple Deconstruction Patterns are in Preview with JEP 433. Is it possible that the Compiler interprets instance of Patterns with Record Classes as Record Patterns?

Nerveless your last Question regarding why input instanceof Triple t raises an error but input instanceof Triple is simpler. The latter is not a Pattern, it’s a Boolean expression and is a permanent feature since the introduction of instance of.

For the record I am not part of the Dev team, I am “only” part of the consuming community 😉

Best Merlin

[1] https://openjdk.org/jeps/394
[2] https://openjdk.org/jeps/433


Merlin Bögershausen
E: Merlin.Boegershausen at rwth-aachen.de<mailto:Merlin.Boegershausen at rwth-aachen.de>
W: https://mboegers.github.io



Von: amber-dev <amber-dev-retn at openjdk.org> im Auftrag von David Alayachew <davidalayachew at gmail.com>
Datum: Montag, 2. Januar 2023 um 05:56
An: amber-dev <amber-dev at openjdk.org>
Betreff: I am having trouble understanding the purpose of Unconditional Patterns


Hello Amber Dev Team,

I was working on some code using Pattern-Matching for instanceof, and then I ran into a surprising warning.

Here is the code.

public class UnconditionalPatternsPreviewWarning
{

   public record Triple(int a, int b, int c) {}

   public static void main(String[] args)
   {

      System.out.println("Java Version = " + System.getProperty("java.version"));

      final Triple input = new Triple(1, 2, 3);

      if (input instanceof Triple t)
      {

         System.out.println("Made it here");

      }

   }

}

And here is the warning.

$ javac -Xlint:preview --enable-preview --release 19 UnconditionalPatternsPreviewWarning.java
UnconditionalPatternsPreviewWarning.java:15: warning: [preview] unconditional patterns in instanceof are a preview feature and may be removed in a future release.
      if (input instanceof Triple t)
                           ^
1 warning

I tried searching for what this warning means, but couldn't find it. More specifically, I couldn't understand what Unconditional Patterns meant. With some help from StackOverflow (https://stackoverflow.com/questions/74978665), I was led to a blog by Nicolai Parlog, which explained the meaning.

> ...an unconditional pattern, that is, a
> pattern that matches all possible
> instances of the switched variable’s type.

I understand the meaning well enough. Basically, it is saying that the compiler knows 100% that a variable is fully and unconditionally matched by the given pattern. Therefore, it is considered an unconditional pattern. As a result, since unconditional patterns are in preview (while instanceof pattern-matching has since been released as General Availability), then I now understand my warning and why it occurred.

But that leads to a couple questions.

The fact that you all made this delineation meant that it is something worth denoting. Why? What about it is so significant that you would denote this? In fact, if I turn off the --enable-preview features flag and the Xlint check, that warning turns into an error for the exact same reason -- my pattern fully encompasses all possible values of my variable. So this is clearly something that needed a big fence put around it.

Is there some (upcoming) functionality involving pattern-matching that depends on this delineation?

Why make this delineation for the following snippet, but not the one below it?

if (input instanceof Triple t) {} //error or warning, depending on what you compile with

if (input instanceof Triple) {} //compiles fine and runs fine

Is it because of backwards compatibility?

Thank you all for your time and your help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230102/845ebd11/attachment-0001.htm>