#23 Restrictions on type parameter names

[Bryn Keller]

Part 1:

I think it would be good to report an error (or at
least a warning) when a type name is used where a type
parameter name is expected. For instance,

//Read lines from a file
class LineIterator<String> implements Iterator<String>
{
//...
}

What was intended here was

class LineIterator<String T> implements Iterator<T>
{
//...
}

but the compiler happily uses "String" as a type
parameter name, leading to much confusion when you find
out that your new LineIterator works with t243's or
something instead of Strings.

Part 2:

Perhaps even better would be to simply accept the first
syntax with the same meaning as the second example.
That is, when we see

class A<X> implements B<X>

and X is the name of a class, treat it as

class A<X T> implements B<T>

this would certainly help convert a certain class of
errors into usable code. Whether we should complicate
the notation with this special case I'm not sure, we
should have some discussion on the subject.

We should definitely implement the error/warning in
Part 1 in the meantime.

[Daniel Bonniot]

Logged In: YES
user_id=88952

I agree the motivating case is confusing, so we should at least issue a warning.

For a good support for this case, I think the solution is as in RFE #994780: allow
class LineIterator implements Iterator<String>

[Daniel Bonniot]

Logged In: YES
user_id=88952

It's now possible to do
class LineIterator implements Iterator<String>

Still, I agree that trying to shadow a toplevel type by a
type variable should not be allowed. It can be the occasion
to do so while updating the generics syntax.