<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="NL-BE" link="blue" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<div>
<pre><span lang="EN-US">This email was initially sent to amber-spec-observers by accident.<o:p></o:p></span></pre>
<pre><span lang="EN-US"><o:p> </o:p></span></pre>
<pre>Hi all</pre>
<pre><o:p> </o:p></pre>
<pre>I've long considered whether I should voice my opinion on</pre>
<pre>the matter or not, given that I felt like some of my</pre>
<pre>arguments had already been made before.</pre>
<pre><o:p> </o:p></pre>
<pre>Spoiler, I'm not a fan of `instanceof byte`.</pre>
<pre><o:p> </o:p></pre>
<pre>Every time I write this email, I recheck something in</pre>
<pre>the archives to check something and realize that someone</pre>
<pre>already said *something* about one of the arguments I'm</pre>
<pre>trying to make. So here is just a list of things that</pre>
<pre>have come up that I still felt like mentioning something.</pre>
<pre><o:p> </o:p></pre>
<pre>---</pre>
<pre><o:p> </o:p></pre>
<pre>I asked a whether the following would be legal in an earlier email.</pre>
<pre>The draft now explains that it is, but I still wonder what this snippet</pre>
<pre>would get desugared to.</pre>
<pre><o:p> </o:p></pre>
<pre>```</pre>
<pre>Number num = ...;</pre>
<pre><o:p> </o:p></pre>
<pre>if (num instanceof byte b) {</pre>
<pre> ...</pre>
<pre>}</pre>
<pre>```</pre>
<pre><o:p> </o:p></pre>
<pre>---</pre>
<pre><o:p> </o:p></pre>
<pre>On 2023-01-27 at 12:01 UTC, Ron Pressler wrote</pre>
<pre>(as reaction to an email by Remi Forax on 2023-01-27 at 11:06 UTC):</pre>
<pre><o:p> </o:p></pre>
<pre>><i> §4.10.1 of the JLS has stated that a subtyping relationship among primitives exists (byte <: short <: int <: long, float <: double) since at least Java 1.6 (possibly earlier).<o:p></o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>>><i> By example, you can not override a method that returns a double with a method that returns an int because overriding is about subtyping relationship, not conversion (for the history, Neal Gafter had implemented method overriding that allow primitive conversions in javac in one of the early versions of Java 1.5 but to it was decided to not go that path).<o:p></o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i> The rules for return types in overridden methods (§8.4.8.3) doesn’t refer to subtyping but to "return-type-substitutability” (§8.4.5) which, in turn, also doesn’t talk about subtyping but only about subtyping *in the case that the return type is a reference type*. So even though there is a subtyping relationship between int and long (though not between int and double), they are not return-type-substitutable, which places additional constraints beyond mere subtyping.<o:p></o:p></i></pre>
<pre><o:p> </o:p></pre>
<pre>It seems you missed a single line in the spec. `long` is also a</pre>
<pre>direct subtype of `float` so `int` is in fact a subtype of `double`</pre>
<pre><o:p> </o:p></pre>
<pre>>><i> I agree that revisiting concepts is something we have to do, but breaking the difference between subtyping and primitive conversions for a corner case, in isolation, is a decision hard to understand.<o:p></o:p></i></pre>
<pre>><i><o:p> </o:p></i></pre>
<pre>><i> First, a subtyping relationship for primitives does exist, though it doesn’t cover all of the possible conversions.<o:p></o:p></i></pre>
<pre>Second, nothing is broken, shattered, or wrecked even in cases subtyping doesn’t exist, because the draft doesn’t propose to *change* the meaning of patterns, but rather to generalise them. I.e. its insight is that subtyping is a special case of assignment conversion, and so patterns are “really” about the validity of such conversions rather than about the specific case of subtyping.</pre>
<pre><o:p> </o:p></pre>
<pre>I had a quick look over the spec and I couldn't find any place that</pre>
<pre>actually used the subtyping relation between primitives. The case</pre>
<pre>you seem to be claiming widening primitive conversion matches 100%</pre>
<pre>with the rules about subtyping, it actually doesn't use subtyping</pre>
<pre>at all and just lists all possible conversions.</pre>
<pre><o:p> </o:p></pre>
<pre>A interesting question that could be asked is:</pre>
<pre>"What does subtype/supertype mean". Although it is used in the spec</pre>
<pre>it isn't really explain apart from being a reflexive and transitive</pre>
<pre>relationship between types.</pre>
<pre><o:p> </o:p></pre>
<pre>---</pre>
<pre><o:p> </o:p></pre>
<pre>A few of the emails argue that we should see `instanceof` as a</pre>
<pre>safe cast check, not like an "inheritance" check or</pre>
<pre>a "reference subtype" check. If the operator was called</pre>
<pre>`canbesafelyconvertedto` I might agree, but thats not the case.</pre>
<pre><o:p> </o:p></pre>
<pre>It feels very weird (to me) to not have an operator called</pre>
<pre>`instanceof`, not check whether the lhs is an instance of the</pre>
<pre>rhs.</pre>
<pre><o:p> </o:p></pre>
<pre>Some of you might be thinking: "I guess you want to argue that</pre>
<pre>you can't have instances of an `byte` so `instanceof byte`</pre>
<pre>doesn't make sense", which isn't true. Valhalla discussions</pre>
<pre>have agreed that `byte` has instances. It has 256 different ones:</pre>
<pre>the values from -128 to 127.</pre>
<pre><o:p> </o:p></pre>
<pre>Now this might seem I'm arguing in favour of `instanceof byte`.</pre>
<pre>And on it's own that might look correct, but then you have</pre>
<pre>justify the fact that the integer values/instances between -128</pre>
<pre>and 127 and the byte values/instances are the same. In my mind</pre>
<pre>the way this would be justified is by using the fact that `byte`</pre>
<pre>is a subtype of `int` which is why it's set of instances is a</pre>
<pre>subset of the instances of `int`. But this raises the issue</pre>
<pre>that the set of instances of `int` can't be a subset of the set</pre>
<pre>of instances of `float` cause not all ints are valid floats.</pre>
<pre><o:p> </o:p></pre>
<pre>---</pre>
<pre><o:p> </o:p></pre>
<pre>I feel like I spend too much time writing, rewriting and deleting this</pre>
<pre>email so this is it (for now).</pre>
<pre><o:p> </o:p></pre>
<pre>TL; DR: I don't like `instanceof byte` and JLS chapter 4.10.1</pre>
<pre><o:p> </o:p></pre>
<pre>Kind regards</pre>
<pre>Robbe Pincket</pre>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>