Type parameters inside super() calls?

[Archie Cobbs]

On Thu, Feb 2, 2023 at 9:03 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 02/02/2023 14:33, Archie Cobbs wrote:
>
> Referring to the example (btw, I forgot to include the return type of the
> method which obviously is float):
>
> - Any call to toFloat() is correct, because T has Number as upper bound.
> Same as if the method were not static and you invoked it on a Foo<?>.
> - If a static method returns T, then the compiler treats this as if it
> returned ? extends Number.
> - The synthetic cast for T would always be to Number
>
> 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.
>
> 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).
>
> 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.
>
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".

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/15cb411c/attachment-0001.htm>