<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">Yeah, I think we are abusing
        the notion of static context here.  It worked pre-generics, but
        there is no reason the class tvars should not be in scope.  And
        when you extend to statements before the super, there's no
        reason they should not be in scope there.  <br>
        <br>
        I think the cure here is to simply update the constructor-body
        logic to say that this region is not a static context, but a
        restricted context in which you can't use this, super, instance
        members, etc.  This is a small and localized change (to spec
        language we're already touching anyway.)<br>
      </font></font><br>
    <div class="moz-cite-prefix">On 2/2/2023 5:25 AM, Maurizio
      Cimadamore wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:46cc73d8-4117-96e4-6f18-b17ed1e69166@oracle.com">
      
      <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>Put another way, a static method is just an instance method
          without a 'this' instance. So neither issue #1 or #2 is
          possible. So, no problem, right?<br>
        </div>
        <div dir="ltr"><br>
        </div>
        <div>You might be able to write code that looks silly, but would
          it actually be nonsensical?<br>
        </div>
        <div dir="ltr"><br>
        </div>
        <div><span style="font-family:monospace">    public class
            Foo<T extends Number> {</span></div>
        <div><span style="font-family:monospace">        public static
            toFloat(T value) {</span></div>
        <div><span style="font-family:monospace">            return
            value.floatValue();   // why not?<br>
          </span></div>
        <div><span style="font-family:monospace">        }<br>
          </span></div>
        <div><span style="font-family:monospace">    }<br>
          </span></div>
        <div dir="ltr"><br>
        </div>
      </blockquote>
      <p>IMHO, this is taking it a step too far.</p>
      <p>As I said, I believe the issue stems from using the "static
        context" trick to put restriction on _expressions_ - which then
        ends up also affecting _types_.</p>
      <p>I do not think the bug has to do with "static context" being
        ill-defined. There is a big difference between using a T in a
        constructor, and using T in a static method:</p>
      <p>* when a constructor is called, you are already initializing a
        _specific_ instance, so T is _bound_;<br>
        * when a static method is called, there is no instance, so T is
        _not bound_, and has no real meaning.</p>
      <p>Allowing access to T from static method as if it was a "real
        thing"  seems like a recipe for disaster: how do we validate
        that a call to `toFloat` is correct? And, if `toFloat` returned
        a T, how do we validate that the return type is also used
        correctly at the callsite? And which synthetic cast should be
        generated (given that T not known?).</p>
      <p>Maurizio<br>
      </p>
    </blockquote>
    <br>
  </body>
</html>