I am having trouble understanding the purpose of Unconditional Patterns

David Alayachew davidalayachew at gmail.com
Mon Jan 2 04:55:53 UTC 2023


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/20230101/c0b80dbc/attachment.htm>


More information about the amber-dev mailing list