Is V? what we need ?

Brian Goetz brian.goetz at
Wed May 8 18:31:52 UTC 2019

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

More information about the valhalla-spec-observers mailing list