<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello <a class="gmail_plusreply" id="plusReplyChip-0" href="mailto:amber-dev@openjdk.org" tabindex="-1">@amber-dev</a>,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">(this is a follow-up from the previous thread -- <a href="https://mail.openjdk.org/pipermail/amber-dev/2025-November/009472.html">https://mail.openjdk.org/pipermail/amber-dev/2025-November/009472.html</a>)</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Since records are <b><i>transparent</i></b> carriers of data, then that means that all of the record components are known at compile time and visible to all consumers who can reach the record itself.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Right now, the only way to reach these record components is by drilling down via j.l.Class ---> j.l.r.RecordComponent. And even then, you are forced into doing String comparison against what you <b><i><u>expect</u></i></b> the record component to be named. That means that you will get a runtime error, not a compile time error, if a record component changes names.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I propose that we enumerate the Record Components of a record.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">My naive way of accomplishing this would be to literally provide each record with its own inner enum, each value corresponding to the respective record component on a record.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Consider the following record.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">record User(String firstName, String lastName, int age) {}</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I ask that record get access to its own inner enum (let's call it VALUES), that can be referenced. Like this.</div><div class="gmail_default" style="font-family:monospace"><br></div><div><div style="font-family:monospace" class="gmail_default">record User(String firstName, String lastName, int age)<br>{<br>    enum Values {<br>        firstName,<br>        lastName,<br>        age,<br>        ;<br>        public final java.lang.reflect.RecordComponent recordComponent =<br>                Arrays<br>                    .stream(User.class.getRecordComponents())<br>                    .filter(rc -> rc.getName().equals(<a href="http://this.name">this.name</a>()))<br>                    .findAny()<br>                    .orElseThrow()<br>                    ;<br>    }<br>}<br></div><br></div><div><div style="font-family:monospace" class="gmail_default">This is better than the current situation for all sorts of reasons.</div><div style="font-family:monospace" class="gmail_default"><ol><li>Currently, if I want a RecordComponent, I must make a String-comparison. I lose compile time safety of checking if my hard-coded string no longer matches because someone changed the record.</li><li>I now get exhaustiveness checking, which really should have been there from the beginning.</li></ol><div>And of course, I am not tied to the idea of using an enum or an inner class. My real goal is to be able to enumerate over the components of a record. Not even necessarily over the j.l.r.RecordComponents of a record. Whatever form that takes is fine with me.</div><div><br></div><div>But not being able to enumerate over a records components (obviously, in a type-safe, non-<b><u><i>stringly</i></u></b>-typed way) is making records less powerful for seemingly no reason. The contract and spec enables it, it's just not being utilized.</div><div><br></div><div>Thank you for your time and consideration.</div><div>David Alayachew</div></div></div></div>