Trouble with wildcards

[Henry Jen]

On 12/17/2013 10:30 AM, Dan Smith 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 return type becomes generic can also cause problem chaining API, I 
think this still valid.

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

That's all I can remember. :)

Cheers,
Henry