Primitive type patterns - an alternative approach (JEP 507)

[Pedro Lamarão]

Hello Stephen!
In your essay, you write:
"A number held as a long is very different to a number held as an int, even
if the number has the same magnitude."
The only difference I can think of about the behaviour is around overflow
or underflow -- because, say, INT_MAX + 1 would give a different result
than ((long) INT_MAX) + 1.
What other differences am I missing?
I'm unsure how these arguments stand when we go all the way down to the
world where a number held as an int in Java is in fact held in a machine
register which is long-wide.
Atte.
Pedro.

Em qua., 15 de out. de 2025 às 03:35, Stephen Colebourne <
scolebourne at joda.org> escreveu:

> In the vein of JEP feedback, I believe it makes sense to support
> primitive types in pattern matching, and will make sense to support
> value types in the future. And I can see the great work that has been
> done so far to enable this.
>
> Unfortunately, I hate the proposed syntactic approach in JEP 507. It
> wasn't really clear to me as to *why* I hated the syntax until I had
> enough time to really think through what Java does in the area of
> primitive type casts, and why extending that as-is to pattern matching
> would IMO be a huge mistake.
>
> (Please note that I fully grasp the pedagogical approach wrt
> instanceof defending an unsafe cast, but no matter how much it is
> repeated, I don't buy it, and I don't believe it is good enough by
> itself.)
>
> To capture my thoughts, I've written up how Java's current approach to
> casts leads me to an alternative proposal - type conversion casts, and
> type conversion patterns:
> https://tinyurl.com/typeconvertjava1
>
> thanks
> Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251015/360e3d3e/attachment-0001.htm>