Primitive type patterns - an alternative approach (JEP 507)

[Stephen Colebourne]

On Thu, 16 Oct 2025 at 17:22, Brian Goetz <brian.goetz at oracle.com> wrote:
> Because all the implicit, type-driven variation in semantics that is present in `anObject instanceof int x` is equally present in `int x = anObject`.  (In fact, it should be, because they are _the same thing_.)

Using one syntax for all kinds of cast is manageable, because the
control flow is *unconditional*.

Using one syntax in patterns for unconditional type checks, partial
type checks and partial type conversions is atrocious, because the
control flow is *conditional*. With conditional control flow
developers absolutely 100% need to be able to read code and know which
branch will be taken. But the current chosen syntax deliberately sets
out to obscure the information needed to read the code.

I understand how you want one syntax to be the inverse of the other.
But as per the previous two paragraphs, they operate in different
problem spaces, and different syntax is entirely justified.

> This feature is about creating level ground for future work to build on -- constant patterns, numeric conversions between `Float16` and `double`, etc.  But to make these features possible, we first have to undo the accidental complexity of past hyperlocal feature design so that there can be a level ground that these features can be built on; the ad-hoc restrictions have to go.

And I agree with all of that. As above, the problem is that the level
ground being created (in patterns) is just too flat.


> Example 2: local variable type inference (`var`)
> In the end, it was mostly a nothingburger.  Developers learned to use `var` mostly responsibly, and there was no collapse in maintainability or readability of Java code.  The fears were unfounded.

var is still hugely controversial. And many developers and shops
refuse to use it, with fear-based responses.

> But I will note that almost all of the example offered involve floating point, which mainstream Java developers _rarely use_.

I don't use any floating point examples, precisely because they are a
red herring obscuring the real issues.

> *If* it turns out, when we get to that future, that things are still too implicit for Java developers to handle, we still have the opportunity _then_ to offer new syntactic options for finer control over conversions and partiality.

Surely a better option would be to put this feature on the back burner
until there are value types and type classes that actually justify it.
I strongly suspect that approach would also yield much better feedback
on whether the outcome is readable or not. And I think the downsides
of delaying are minimal.

Thanks as always for your thoughts,
Stephen