Type parameters inside super() calls?

[Maurizio Cimadamore]

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.

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/84a86c87/attachment-0001.htm>