Question on Primitive Types in Patterns

[David Alayachew]

Puzzlers aside, can we get a definitive answer on why this is this way? I
want to understand the semantics by the compiler that made this possible,
so that I can understand why it is being considered legal by the compiler.
Is what Deepak says is true?

On Fri, Sep 5, 2025 at 12:46 PM Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Original Message -----
> > From: "Brian Goetz" <brian.goetz at oracle.com>
> > To: "Simon Ritter" <sritter at azul.com>, "amber-dev" <
> amber-dev at openjdk.org>
> > Sent: Friday, September 5, 2025 4:30:06 PM
> > Subject: Re: Question on Primitive Types in Patterns
>
> >>
> >> I've been giving a presentation on Patterns in the Java language and
> >> including some puzzles.  The recent inclusion of Primitive Types in
> >> Patterns has provided some interesting material.  I currently have one
> >> puzzle that I can't quite explain; hopefully someone on the mailing
> >> list can provide clarification.
> >
> > On a pedagogical note, I'd like to make a case for "Java Puzzlers Talks
> > Considered Harmful."  They can be fun to write (which is why we get so
> > many of them), but I have found that the vast majority of time, a good
> > chunk of the audience comes away with notions that are closer to "XYZ is
> > broken", "XYZ is just all ad-hoc complexity", or "XYZ has no organizing
> > design principle" -- even though this is rarely the intent of the
> > presenter (often the opposite, in fact.)
> >
> > When Josh and Neal started with Puzzlers, they could at least come from
> > the position of "these were some arguably-mistakes that *we* made".  Not
> > only did this give them credibility that almost no other "Java Puzzlers"
> > presenter could have, but it pushed them to dig deeper to present
> > language design tradeoffs _from the perspective of language designers_.
> >
> > I cannot count the number of times where someone has seen a "puzzler"
> > presentation or blog, and learned the exact opposite lesson than it was
> > trying to teach.   This is an extraordinarily difficult format for
> > teaching.  Worse, the nature of a "Puzzlers" talk requires having a
> > bunch of them, and -- even when Josh and Neal did it -- there were
> > always a few that didn't live up to the standards; the format often
> > overtakes the message.  It is just a truly punishing format, one that
> > requires world-class pedagogy and impeccable preparation to avoid the
> > all-too-common outcome where many in the audience learn the wrong lesson
> > (often reinforcing their preconceived but ill-examined assumptions about
> > "X is bad.")
>
> This is a preview feature, so for me finding corner cases is fair game.
> It help us to understand the tradeoffs of this feature.
>
> There are always puzzlers, for every features, but there are two
> categories of puzzlers:
> - those that enlighten you (like this is why Foo behave different as a top
> level pattern or as an inner pattern),
>   as you said, it's quite hard to convey that in a presentation.
> - those that just show the designers being too clever (lets make ?: boxing
> rules different)
>   or the feature being consistent only with itself and not with the rest
> of the world (the X cross Y problem).
>
> regards,
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250905/7413e386/attachment.htm>