<div dir="ltr"><div dir="ltr">On Thu, Feb 2, 2023 at 9:03 AM 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>
    <p>On 02/02/2023 14:33, Archie Cobbs
      wrote:
    </p>
    <blockquote type="cite">
      <div>Referring to the example (btw, I forgot to include the return
        type of the method which obviously is <span style="font-family:monospace">float</span>):</div>
      <div><br>
      </div>
      <div>- Any call to <span style="font-family:monospace">toFloat()</span>
        is correct, because <span style="font-family:monospace">T</span>
        has <span style="font-family:monospace">Number</span> as upper
        bound. Same as if the method were not static and you invoked it
        on a <span style="font-family:monospace">Foo<?></span>.</div>
      <div>- If a static method returns T, then the compiler treats this
        as if it returned <span style="font-family:monospace">? extends
          Number</span>.</div>
      <div>- The synthetic cast for <span style="font-family:monospace">T</span>
        would always be to <span style="font-family:monospace">Number</span></div>
      <div><br>
      </div>
      <div>I'm NOT saying that allowing static methods would be an
        intuitive and obviously beneficial addition to the language. I'm
        just saying that it could be done in a reasonably coherent way.
        The point of that is just to provide more evidence that it's NOT
        automatically true that type parameters should be forbidden from
        static contexts.<br>
      </div>
      <div>
        <div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>There are indeed more ways to get there - but I believe that this
      particular way doesn't seem very economical - because different
      occurrences of T in different methods (static vs. instance) end up
      having different semantics. Which seems indesirable and put (as
      Remi observed) this on collision course with any attempt to add
      "species statics" later on (e.g. specialization-specific type
      parameters).</p>
    <p>So, in abstract terms I agree with you; for the specific case of
      the Java language we have, I tend to disagree - regular type
      parameters and static contexts don't seem a good fit.<br></p></div></blockquote><div>We do agree - I don't think it's a good fit either. I'm just saying it's an interesting thought experiment, and it shows that types don't NEED to be excluded from static contexts "in abstract terms".<br></div><div><br></div><div>-Archie<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>