Type parameters inside super() calls?

[Brian Goetz]

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.

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

On 2/2/2023 5:25 AM, Maurizio Cimadamore wrote:
>
>
> 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?).
>
> Maurizio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230202/cc595ccb/attachment.htm>