<div dir="auto">If I were to propose the solution, I would make implementation of methods that return this.class uninheritable if its parent impl not returns this.class type, i.e. each subtype obliged to redefine method unless it's parent delegates return to a method that returns this.class itself. Effectively this would mean that each type must redefine end of each chain of methods that return this.class. This would reduce inheritence effort to effectively having to override 1 (in good design) supplier method and still allow to inherit actual logic from super classes.<div dir="auto"><br></div><div dir="auto">Although, I must say that implementing such feature would be a headache for sure. You must account all corner cases if adopting approach I described, because, at least to me, it seems a bit shaky. </div><div dir="auto"><br></div><div dir="auto">Also, I am not sure that complexity of this approach really justified by solved problem. I feel like, whatever you can come up with, it is either incredibly complex or not very effective at solving described problems</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2024, 00:05 Johannes Spangenberg <<a href="mailto:johannes.spangenberg@hotmail.de">johannes.spangenberg@hotmail.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
  <div>
    <p>
      <blockquote type="cite">and any implementation of withFoo() would
        just have to return an object with type compatible with
        Builder<T>.</blockquote>
    </p>
    <p>With these rules, the compiler would allow the following code,
      although it is broken:</p>
    <blockquote>
      <pre>public class Builder { // May have sub-types
    ...
    this.class copy() {
        return new Builder(this);
    }
    ...
}
</pre>
    </blockquote>
    <p>Anyway, there are probably solutions to make it work in most
      situations using more elaborate rules for the type system. I guess
      you could also argue that it is OK that the compiler cannot detect
      the broken code above, and the application should just throw a <font face="monospace">ClassCastException</font>. After all, it
      wouldn't be the only case where broken code is not detect at
      compile time. However, I think such change would require careful
      consideration of different solutions to the problem (and whether
      the problem justifies special syntax and rules).</p>
  </div>

</blockquote></div>