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 < [email protected]> 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
