<div dir="ltr">(nonauthoritative opinion)<br><br>For the first point: While it has its downsides, that capability already exists in the form of code generating annotation processors.<br><br>I.E. it is possible to have<br><br><font face="monospace">@Ordered<br>public record Hill(int heightAboveSeaLevel) <br>        implements HillComparable {<br>}</font><div><font face="monospace"><br></font></div><div><font face="arial, sans-serif">Generate<br><br></font><font face="monospace">interface HillComparable extends Comparable<Hill> {</font><br><font face="monospace">    @Override</font><br><font face="monospace">    default int compareTo(@NotNull Hill o) {</font><br><font face="monospace">        return Comparator</font><br><font face="monospace">                .comparingInt(Hill::heightAboveSeaLevel)</font><br><font face="monospace">                .compare(this, o);</font><br><font face="monospace">    }</font><br><font face="monospace">}</font><br><br><font face="arial, sans-serif">The problem is that all such code generators - if they were built into the language - would have restrictions on the contexts in which they are applicable. Fundamentally records can only have toString, equals, and hashCode derived for them because by virtue of being a record the language knows that it is just a thin data carrier. It is much  more dubious to do something similar for regular classes.</font></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Dec 5, 2024 at 9:02 PM Gavin Bierman <<a href="mailto:gavin.bierman@oracle.com">gavin.bierman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
I can speak to the second point: Yes, this is very much on our radar. There has been discussion of this on this list I believe (or maybe on the spec-experts list), and it is mentioned in early design documents that you can read on the Amber project page [1]. 
<div><br>
</div>
<div>There are other places that we would like to consider to support patterns, e.g. in the head of lambda expressions and in enhanced for statements. We may well do these all in one go.</div>
<div><br>
</div>
<div>Thanks for your interest!</div>
<div>Gavin</div>
<div><br>
</div>
<div>[1]: <span style="white-space:pre-wrap"> </span><a href="https://openjdk.org/projects/amber/design-notes/patterns/pattern-match-semantics" target="_blank">https://openjdk.org/projects/amber/design-notes/patterns/pattern-match-semantics</a></div>
<div><span style="white-space:pre-wrap"></span><a href="https://openjdk.org/projects/amber/" target="_blank">https://openjdk.org/projects/amber/</a></div>
<div><br id="m_-512231407546079143lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 5 Dec 2024, at 09:34, vab2048 <<a href="mailto:vab2048@gmail.com" target="_blank">vab2048@gmail.com</a>> wrote:</div>
<br>
<div>
<div>Hi Amber team,<br>
<br>
I was wondering about the future of two different features and thought I would just ask the mailing list.<br>
<br>
The first feature: deriving instances. <br>
<br>
Haskell allows type declarations to derive instances for certain type classes (Eq, Ord, Enum, Bounded, Show, and Read).<br>
<br>
Is it possible to get some sort of equivalent for java classes which would allow us to specify to the compiler to auto derive some code. I am thinking about easily auto-generating a toString, equals, hash code etc? We already have a form of this for records,
 and so bringing it to classes would make a logical next step. <br>
<br>
The second feature: pattern matching on LHS of assignment.<br>
<br>
Suppose we have this record type:<br>
<br>
record Color(byte red, byte green, byte blue) {}<br>
<br>
and a static factory method “someFactory” which returns a Color.<br>
<br>
Are there any plans to allow us to pattern match at the point of assignment like so:<br>
<br>
Color(byte red, byte green, byte blue) color = someFactory();<br>
<br>
This would be a great addition to pattern matching.<br>
<br>
<br>
Regards,<br>
<br>
Vikram<br>
<br>
<br>
<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>

</blockquote></div>