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