But that's only repeating my question in different words. I'm looking for any
sort of justification for what appears (to me) to be an absurd restriction.
/Why/ is the type parameter only "available" to instance-side code ? What
possible advantage does that give, either to the semantics of the language, or
to the implementations ? /I/ cannot think of any at all, but maybe I'm missing
something.
<ponders>
Would it have been better to forbid only static fields, I wonder ? That would
certainly be more irregular that forbidding static members altogether, but
generics are so irregular anyway, that the incremental downside might have
been smaller than the gain.
</ponders>
I am a rank amateur when it comes to type theory, but in my limited
understanding of the subject I am going to suggest that you are
commingling the distinct concepts of a type /parameter/ and its
corresponding type /argument/, and perhaps overlooking the (now
stronger) differences between class and type. Type parameters are
properties of a generic class, just as static members are, but the
corresponding type arguments bound to those parameters are properties of
particular type instances (by which I am referring to types, not
objects). It is not the type parameters that are inaccessible to static
methods, but rather the type arguments.
Granted, that's a somewhat hand-waving argument. You could imagine
binding a type argument at the point of invocation, something like this:
Test<X>.x();
But if you need to do that, then it is no less work than Ingo's
suggestion to use a generic method instead, whose invocation would look
like this (without type inference):
Test.<X>x();
Furthermore, the first alternative (type parameter usable by static
methods) runs into all the normal confusion with invocation of static
methods on references, but compounded by the fact that the relevant type
argument is not that of the reference's type (to the extent that that
exists in the presence of type erasure), but rather that of the
expression's type.