Type parameters inside super() calls?

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Feb 2 10:25:10 UTC 2023

On 02/02/2023 02:04, Archie Cobbs wrote:
> 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?
> You might be able to write code that looks silly, but would it 
> actually be nonsensical?
>     public class Foo<T extends Number> {
>         public static toFloat(T value) {
>             return value.floatValue();   // why not?
>         }
>     }
IMHO, this is taking it a step too far.

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_.

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:

* when a constructor is called, you are already initializing a 
_specific_ instance, so T is _bound_;
* when a static method is called, there is no instance, so T is _not 
bound_, and has no real meaning.

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?).

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

More information about the compiler-dev mailing list