Trouble with wildcards
henry.jen at oracle.com
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 oracle.com>
>> On Dec 17, 2013, at 12:10 AM, Zhong Yu <zhong.j.yu at gmail.com>
>>> 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
>>> 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  and i can no longer recall why, perhaps Henry can
> 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