<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">Indeed.  The "return on
        complexity" (RoC) is weak at best.</font></font><br>
    <br>
    <div class="moz-cite-prefix">On 1/28/2023 4:49 PM, Maurizio
      Cimadamore wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:6ad45d5b-6a8e-4859-1c6b-02cfb486d53b@oracle.com">
      <br>
      On 28/01/2023 02:19, John Rose wrote:
      <br>
      <blockquote type="cite">I must be missing your point here
        Maurizio… There is
        <br>
        some corner case you are concerned with but I can’t see
        <br>
        where the danger is.
        <br>
      </blockquote>
      <br>
      My point was not about "danger" but about "complex programming
      model", and "return on complexity". Allowing initialization of
      local fields before super() call would at the very least cause
      observable behavior changes in all the instance initializers of
      the class (there was such an example in the previous version of
      the JEP I believe).
      <br>
      <br>
      So my point was: why do we need to go there? That is not (anymore)
      about allowing programs which were rejected for obtuse reasons.
      This starts going down a path of messing with initialization order
      (e.g. moving a field initializer, even if local, across the
      "super" call is _not_ a compatible change).
      <br>
      <br>
      It maybe failure of imagination - but aside from pathological
      cases (like classes whose initialization lets `this` escape -
      which I think we all agree are on the bad side of the spectrum) I
      can't think of why you would want to do that. The fact that the
      JVM allows it, and that it does so in a sound fashion (which is
      what I'd expect the JVM to do) is irrelevant in my consideration.
      <br>
      <br>
      To put it more clearly - it is quite clear as to why one might
      want to:
      <br>
      <br>
      * do validation on constructor parameter before a super call
      <br>
      * pass constructor parameter twice
      <br>
      * do some complex initialization which requires control flow
      <br>
      <br>
      These are things that add a net improvement on language
      expressiveness, and do that with a very simple rule: you cannot
      spell `this` before the super() call, which is easy to remember,
      and close to what users would expect.
      <br>
      <br>
      To add the next bit, the model is: you cannot spell `this` except
      if it's an initializer of a field. But wait, not any field, it has
      to be a "local" field (this names is, btw, not great, as in Java I
      only know about "local variables") - so that concept also comes
      with the ride. Of course these concepts aren't hard to teach, but
      I think before we go there we should have better arguments of
      _why_ we need to, as the examples I've seen so far seem a bit on
      the thin side. And, doing the points above doesn't prevent us from
      doing more later, if needed.
      <br>
      <br>
      Cheers
      <br>
      Maurizio
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>