Trouble with wildcards

[Dan Smith]

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.

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

—Dan