<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 02/02/2023 02:04, Archie Cobbs
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com">
      <div>The example <span class="gmail-im"><span style="font-family:monospace">super(new Local().aString())</span>
        </span>can never be allowed, because of #2 above. But note you
        can <i>define</i> Local prior to <span style="font-family:monospace">super()</span> ... you just
        can't instantiate it. <br>
      </div>
      <div><br>
      </div>
      <div>In other words the type itself is not a problem. There's no
        mention of types at all in the above two reasons.<br>
      </div>
    </blockquote>
    Exactly - I came up with the same conclusion in my long-winded reply
    to myself :-)<br>
    <blockquote type="cite" cite="mid:CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com">
      <div><br>
      </div>
      <div>So one thought experiment is: What would happen if we
        eliminated all restrictions on generic type parameters in static
        contexts? What would actually go wrong?</div>
    </blockquote>
    <p>I don't think anything can _go wrong_ - because, as I also said
      in my email, the constructor code will have to manipulate
      expression with those types _regardless_ of whether their types is
      manifest or not. So, the language is already behaving as if the
      arguments to the supercall were type-checked in a non-static
      context, otherwise my perfectly legal example:</p>
    <p>```java<br>
      class Sup<X> {<br>
          Sup(X x) { ... }<br>
      }<br>
      <br>
      class Sub<Y> extends Sup<Y> {<br>
         Sub(Y y) {<br>
              super(y);<br>
         }<br>
      }<br>
      ```<br>
      <br>
      Should be rejected (as `y` has no valid type in a static context).
      And I don't think anyone is willing to go down this path.</p>
    <p>In other words, my angle is the opposite: if javac blindly
      followed the "static context" rule, what would happen to existing
      code? What could go wrong? And my answer there was: quite a bit,
      actually. Which leads me to think that the "static" rule, while
      fine in a pre-generics world (and in a world where super calls are
      the first statement in a constructor) is a good and concise way to
      say what we mean. But, in a post-generics world, conflating types
      with expressions (and initializaton only cares about the latter)
      leads to problems - at least if restrictions are to be interpreted
      literally.<br>
    </p>
    <p>Maurizio<br>
    </p>
  </body>
</html>