Question on Primitive Types in Patterns

[Remi Forax]

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