<div dir="auto">Hi Brian, <div dir="auto"><br></div><div dir="auto">I might have worded question incorrectly, but it was about the idea of marking (which we need) on component vs derived fields. Why would we choose one over the other irrespective of the syntax used to achieve that?</div><div dir="auto"><br></div><div dir="auto">I still need to understand your response, but thanks for the response.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 14 Jan, 2026, 9:14 am Brian Goetz, <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</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>
    <font size="4" face="monospace">First, a gentle reminder that I did
      ask "please, let's not discuss syntax."  It is way too early for
      that; we haven't even had a discussion on the value of the ideas
      yet.  But people can't help but obsess on syntax, so I'll answer,
      but please let's let this thread end here.  <br>
      <br>
      Yes, we considered matching on name and type only.  There is
      nothing about that approach that makes it unworkable, but it is
      less reliable, and subjectively, seems to be more likely to feel
      "magic" or "action at a distance" to the Java developers we showed
      this to.  By comparison, the overhead of the `component` modifier
      is small; it is purely horizontal rather than vertical, and admits
      no question about which fields are component fields or not.  It
      also admits greater flexibility for users (under the implicit
      approach, we'd almost certainly want to error out if the names
      matched but the types didn't; with the explicit version, we can
      accept examples like the AlmostRecord in the writeup.)  <br>
      <br>
      Basically: the value of the clarity seems to outweigh the value of
      the concision.  )(And, as you point out, a new modifier would
      still be needed for "not component" in that case.)  <br>
      <br>
    </font><br>
    <div>On 1/13/2026 10:25 PM, Ganapathi Vara
      Prasad wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">Hello Brian,
        <div dir="auto"><br>
        </div>
        <div dir="auto">Thank you for thinking on this feature. I want
          to better understand the thought process behind marking all
          fields that are part of the component state instead of only
          the derived fields. Something like this:</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">```</div>
        <pre>class Point(int x, int y) {
     private final int x;
     private final int y;
     private final derived double norm;

     Point {
         norm = Math.hypot(x, y);
     }

     public double norm() { return norm; }

     // derived implementation of x and y accessors
     // derived implementation of equals, hashCode, toString
}
```</pre>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div>