<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr>, "amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Sent: </b>Wednesday, September 10, 2025 3:03:43 PM<br><b>Subject: </b>Re: Primitive type pattern (as actually specified) is considered harmful<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4" face="monospace">> considered harmful<br><br>
We can add that to the list of phrases that Remi is not allowed to
utter on this list. <br><br><blockquote>
<pre class="moz-quote-pre"># This is the wrong semantics</pre>
</blockquote><br>
I believe we've discussed several time how this is the "wrong" way
to make your case. </font><font size="4" face="monospace">But,
presentation aside, I can't really figure out which argument you
are actually trying to make. <br><br>
What I see, though, in your objections, is a classic fallacious
pattern: <br>
- language already has features X_i (for i in 0..N, N is large)<br>
- language adds feature Y, which is orthogonal to all X_i<br>
- the combination of Y and X_4302 is "confusing"<br>
- Y gets blamed<br>
- the inevitable bargaining begins, where it is attempted to make
Y 1000x more complicated to avoid this particular interaction<br><br>
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. </font></blockquote><div><br></div><div>I agree, i disagree about the proposed semantics, not about the idea to extend instanceof/switch to primitives.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4" face="monospace"><br><br>
To be clear, here's what's going on:<br><br>
- 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". <br>
- 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. <br>
- 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. <br>
- Type patterns for primitives are built on instanceof in the
same way that they are for reference types. <br><br>
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.</font></blockquote><div><br></div><div>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.</div><div><br data-mce-bogus="1"></div><div>So different kinds of casts (primitive, object) have different meanings for what "safe" means.</div><div>An object cast can throw a runtime exception, a primitive cast can not throw but does a lossy conversion instead.</div><div><br data-mce-bogus="1"></div><div>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.</div><div><br data-mce-bogus="1"></div><div>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 ==).</div><div>- with Object o = "foo", o instanceof String s is safe because o.getClass() == String and o == s</div><div>- with Object o = new Integer(3), o instanceof int i is safe because o.getClass() == Integer and o == i.</div><div><br data-mce-bogus="1"></div><div>Your interpretation has several issues:</div><div>- you define "safe" as the revert operation on something which can be lossy (my brain can not compute that),</div><div>- different values of the same class can be converted into different types,</div><div>- 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) *</div>- your interpretation is surprising when i've tried to explain it to others people (even to people coming to JUGs).<div><br></div></div><div data-marker="__QUOTED_TEXT__">regards,</div><div data-marker="__QUOTED_TEXT__">Rémi</div><div data-marker="__QUOTED_TEXT__"><br data-mce-bogus="1"></div><div data-marker="__QUOTED_TEXT__">* 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.</div><div data-marker="__QUOTED_TEXT__"><br data-mce-bogus="1"></div></div></body></html>