Is V? what we need ?

[Brian Goetz]

> 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.  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20190508/d5977c69/attachment.html>