<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">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. <br>
<br>
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.)<br>
</font></font><br>
<div class="moz-cite-prefix">On 2/2/2023 5:25 AM, Maurizio
Cimadamore wrote:<br>
</div>
<blockquote type="cite" cite="mid:46cc73d8-4117-96e4-6f18-b17ed1e69166@oracle.com">
<p><br>
</p>
<div class="moz-cite-prefix">On 02/02/2023 02:04, Archie Cobbs
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANSoFxvzgaz4y-dNvk0N96bAoQEkZoK6gOPCYPGTtjoWE+TqSA@mail.gmail.com">
<div>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?<br>
</div>
<div dir="ltr"><br>
</div>
<div>You might be able to write code that looks silly, but would
it actually be nonsensical?<br>
</div>
<div dir="ltr"><br>
</div>
<div><span style="font-family:monospace"> public class
Foo<T extends Number> {</span></div>
<div><span style="font-family:monospace"> public static
toFloat(T value) {</span></div>
<div><span style="font-family:monospace"> return
value.floatValue(); // why not?<br>
</span></div>
<div><span style="font-family:monospace"> }<br>
</span></div>
<div><span style="font-family:monospace"> }<br>
</span></div>
<div dir="ltr"><br>
</div>
</blockquote>
<p>IMHO, this is taking it a step too far.</p>
<p>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_.</p>
<p>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:</p>
<p>* when a constructor is called, you are already initializing a
_specific_ instance, so T is _bound_;<br>
* when a static method is called, there is no instance, so T is
_not bound_, and has no real meaning.</p>
<p>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?).</p>
<p>Maurizio<br>
</p>
</blockquote>
<br>
</body>
</html>