Primitive type pattern (as actually specified) is considered harmful

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, September 10, 2025 3:03:43 PM
> Subject: Re: Primitive type pattern (as actually specified) is considered
> harmful

> > considered harmful

> We can add that to the list of phrases that Remi is not allowed to utter on this
> list.

>> # This is the wrong semantics

> I believe we've discussed several time how this is the "wrong" way to make your
> case. But, presentation aside, I can't really figure out which argument you are
> actually trying to make.

> What I see, though, in your objections, is a classic fallacious pattern:
> - language already has features X_i (for i in 0..N, N is large)
> - language adds feature Y, which is orthogonal to all X_i
> - the combination of Y and X_4302 is "confusing"
> - Y gets blamed
> - the inevitable bargaining begins, where it is attempted to make Y 1000x more
> complicated to avoid this particular interaction

> One reason that this is an unhelpful way to go about things is that it is
> optimizing for the wrong thing. The extension of instanceof to primitive types
> is utterly simple and straightfoward, and consistent with its meaning for
> reference types; the simplicity of this is a source of strength.
I agree, i disagree about the proposed semantics, not about the idea to extend instanceof/switch to primitives. 

> To be clear, here's what's going on:

> - Today, for reference types, `x instanceof T` asks "can the reference x be
> safely cast to T", where "safe" means "not null, and conversion without CCE".
> - A language that has casts needs instanceof (or the equivalent), since you
> should be able to ask "would it succeed" before doing something that might
> fail.
> - We extend the interpretation `x instanceof T` to _all_ types, appealing to the
> same rule: would casting be safe. We extend the interpretation of "not safe" as
> "losing data" in addition to errors.
> - Type patterns for primitives are built on instanceof in the same way that they
> are for reference types.

> That's it; that's the whole feature. But, because it is built on casting, to the
> degree that you might be confused by casting, you will be confused (in exactly
> the same way) by instanceof.
The idea to uses the same syntax "cast" for different things comes from C/C++, C++ was later changed to recognize that it was a mistake to use the same syntax for different semantics. 

So different kinds of casts (primitive, object) have different meanings for what "safe" means. 
An object cast can throw a runtime exception, a primitive cast can not throw but does a lossy conversion instead. 

As you said, the idea of this JEP is to extend the interpretation of what safe/not safe means, but your interpretation is not the only possible interpretation. 

A more reasonable interpretation, is that "safe" means it's that you get the ""same"" original value (same being defined as: getClass (or subclass) and ==). 
- with Object o = "foo", o instanceof String s is safe because o.getClass() == String and o == s 
- with Object o = new Integer(3), o instanceof int i is safe because o.getClass() == Integer and o == i. 

Your interpretation has several issues: 
- you define "safe" as the revert operation on something which can be lossy (my brain can not compute that), 
- different values of the same class can be converted into different types, 
- it does not work well with Valhalla, especially with the phase 3 (i.e. let's pretend that a primitive type is a value type) * 
- your interpretation is surprising when i've tried to explain it to others people (even to people coming to JUGs). 

regards, 
Rémi 

* record Point(Integer! x, Integer! y) {} and record Point(int x, int y) does not behave the same way with the semantics you have defined. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20250910/866bd653/attachment.htm>