Trouble with wildcards

[Zhong Yu]

On Tue, Dec 17, 2013 at 12:30 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> On Dec 17, 2013, at 4:56 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>> On Dec 17, 2013, at 12:10 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>>> Not exactly sure what you guys are talking about... but I guess it's a
>>> complaint about the signature of Predicate.and()?
>>>
>>> It might be changed to be more receptive, like
>>>
>>>   <S extends T> Predicate<S> and(Predicate<? super S> other)
>>>
>>> then the previous examples could be compiled, as well as this one
>>>
>>>   Predicate<Serializable> p1 = null;
>>>   Predicate<CharSequence> p2 = null;
>>>   Predicate<String> p3 = p1.and(p2);
>>>
>>
>> Thanks, we used a similar trick with Comparator.thenComparing but removed it [1] and i can no longer recall why, perhaps Henry can though.
>
> Yes, this would solve the problem, and it is essentially the same thing as the proposed Comparator.thenComparing change.
>
> As I recall, two arguments for reverting 'thenComparing':
>
> - It makes the method generic in its return type, which changed the dependencies for overload resolution, and thus led to ambiguities.  I think this is a moot point now, because overload resolution isn't going to look at an implicit lambda body in any case.  (And besides, Predicate.and isn't overloaded.)
>
> - The exact same pattern should be used with naturally covariant types (see, e.g., Optional.orElse), but we can't express "S super T" when we declare S.  It is kind of arbitrary to only do this for the (less common) naturally contravariant types.

Contravariance in function types is very common because most functions
accept args. And "S super T" was considered rarely needed.

It is a shame to remove a useful feature to maintain some sense of
symmetry that nobody cares. Remi's example is very reasonable; if it
cannot be supported by Java, it's incumbent on the Java team to supply
a workaround.


>
> There may have been one or two other reasons that I can't recall right now.
>
> —Dan
>