<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 13/06/2023 18:17, Tomáš Bleša wrote:<br>
</div>
<blockquote type="cite" cite="mid:0F2DB659-9B60-484C-8C69-0F6867D02A92@anneca.cz">“<i class="">returns the same instance it is called on</i>”. The
fact that it is also the same type is a useful byproduct. Please
note that I used lowercase T to emphasize it is the instance not
type.</blockquote>
<p>I see what you mean, but what you are describing here is dynamic
behavior - e.g. how a method with returning "this" should be
evaluated. The question remains: what is the static type of "this"
in a method declaration? The JLS and the compiler would have to
define that, and that's why at some point you veer into self-type
territory. Granted, you *could* define the static type of Foo::m
where the method return "this" as Foo - e.g. a weaker self-type,
which is derived from the receiver expression seen from the
compiler.</p>
<p>Your translation strategy should not, thus, use "void" as a
return type, but use whatever T the type is assumed to be at
compile-time. There *has* to be a type there, otherwise it is not
clear how the compiler can type-check a call to a method returning
"this". This is not just about bytecode, and I believe your
emphasis on coming up with a translation scheme which minimizes
passing receiver back and forth might be misguided (after all, we
have an optimizing compiler that will likely take care of that
problem - via inlining - among other things).</p>
<p>As far as I understand, the possible benefits are:</p>
<p>* user can omit "return this" inside the method body<br>
* covariant override are automatically added in subclasses</p>
<p>Note that a better way to achieve same benefits is with the
"wither" approach proposed by Brian sometimes ago:</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md">https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md</a></p>
<p>IMHO, that proposal addresses the issue of dealing with immutable
data at a much deeper level. <br>
</p>
<p>Maurizio<br>
</p>
</body>
</html>