<div dir="ltr"><div dir="ltr">On Thu, Jan 26, 2023 at 1:19 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

  
  <div>On 26/01/2023 18:16, Archie Cobbs
      wrote:<br>
    
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr">On Thu, Jan 26, 2023 at 11:00 AM Maurizio
          Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>>
          wrote:</div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div>I agree that the behavior you propose is not
              problematic per se.
              <p>But, as I mentioned, it brings up can of worms. For
                instance, now a superclass constructor could see its
                field with a non-zero value. Which could definitively be
                surprising. After all, there might be code in the wild
                assuming that an int field that has not been assigned
                yet has value zero - whether writing code like that is
                good or bad, it's a separate question. My point here is
                that here you cross a fine line between  "let's make the
                language more expressive" and "this change might have
                some compatibility impact".<br>
              </p>
            </div>
          </blockquote>
          <div>Yes, but for this to happen the subclass would have to be
            in effect intentionally subverting the superclass
            constructor.<br>
          </div>
          <div><br>
          </div>
          <div>In other words, a problem like you describe can't
            suddenly just start happening "by accident" just because
            this new feature exists...</div>
        </div>
      </div>
    </blockquote>
    <p>Well, you could have a subclass (in some client jar) which
      "subverts" as you say, some superclass in a library. Perhaps the
      library was not prepared for that kind of behavior, and now
      there's a new bug.</p>
    <p>IMHO, we should try to stay well clear of that can of worms. It's
      not like we have to open it now either - the other things you
      propose are 100% non-controversial.</p></div></blockquote><div><br></div><div>So what do you think then of only allowing access to <i>local</i> fields prior to super()?</div><div><br></div><div>Seems like this draws the boundary more tightly around the functionality we're actually aiming for, and keeps out the wormy stuff.<br></div><div><br></div><div>-Archie<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>