> Here comes the parallel with Integer, the way we use Integer currently is, i
> believe, the way we should use V*. It's fine to use V* as a type argument,
> it's fine to use it in a field if you want the reference semantics or a null
> value. It's not fine to use Integer as parameter of a method. That's why i
> think V* should not have the fully crippled semantics, but a kind of
> in-between.
I think there are two points of disagreement here:
1. The meaning of “not fine”.
2. Whether the language should attempt to make such things impossible.
So, while I agree that it is _generally_ a smell to write APIs that have
Integer as parameter or return types, but that doesn’t mean that _any_ such use
is an error, and I certainly don’t think that Integer should not be denotable
as a parameter type.
Here’s an example of how a param/return type of Integer arises naturally:
interface Foo<T> { T mangle(T t); }
class C implements Foo<Integer> {
Integer mangle(Integer i) { … }
}
If it’s OK to say Foo<Integer>, and it’s OK for a class to specialize the
generic type arguments of its super types, then it has to be OK to use Integer
as a parameter or return type. Similarly, what if Foo was:
interface Foo<T> {
void process(Consumer<T> c);
}
clients of C might well want to explicitly type their lambdas as (Integer i) ->
….
Now, s/Integer/V?/:
class D implements Foo<V?> {
V? mangle(V? v) { … }
}
Same argument. While I wouldn’t encourage people to write APIs that make heavy
use of V?, the natural flow of generic types into signatures will occasionally
make it happen, and that’s OK.
