Type parameters inside super() calls?

[Maurizio Cimadamore]

On 02/02/2023 02:04, Archie Cobbs wrote:
> The example super(new Local().aString()) can never be allowed, because 
> of #2 above. But note you can /define/ Local prior to super() ... you 
> just can't instantiate it.
>
> In other words the type itself is not a problem. There's no mention of 
> types at all in the above two reasons.
Exactly - I came up with the same conclusion in my long-winded reply to 
myself :-)
>
> So one thought experiment is: What would happen if we eliminated all 
> restrictions on generic type parameters in static contexts? What would 
> actually go wrong?

I don't think anything can _go wrong_ - because, as I also said in my 
email, the constructor code will have to manipulate expression with 
those types _regardless_ of whether their types is manifest or not. So, 
the language is already behaving as if the arguments to the supercall 
were type-checked in a non-static context, otherwise my perfectly legal 
example:

```java
class Sup<X> {
     Sup(X x) { ... }
}

class Sub<Y> extends Sup<Y> {
    Sub(Y y) {
         super(y);
    }
}
```

Should be rejected (as `y` has no valid type in a static context). And I 
don't think anyone is willing to go down this path.

In other words, my angle is the opposite: if javac blindly followed the 
"static context" rule, what would happen to existing code? What could go 
wrong? And my answer there was: quite a bit, actually. Which leads me to 
think that the "static" rule, while fine in a pre-generics world (and in 
a world where super calls are the first statement in a constructor) is a 
good and concise way to say what we mean. But, in a post-generics world, 
conflating types with expressions (and initializaton only cares about 
the latter) leads to problems - at least if restrictions are to be 
interpreted literally.

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