Trouble with wildcards

Henry Jen henry.jen at
Tue Dec 17 10:48:17 PST 2013

On 12/17/2013 10:30 AM, Dan Smith wrote:
> On Dec 17, 2013, at 4:56 AM, Paul Sandoz <paul.sandoz at>
> wrote:
>> On Dec 17, 2013, at 12:10 AM, Zhong Yu <zhong.j.yu at>
>> 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. :)


More information about the lambda-dev mailing list