Overload resolution simplification
michael.hixson at gmail.com
Fri Aug 16 17:43:43 PDT 2013
>> That's precisely what I was getting at. If the current situation is
>> no better than the one that led to removing the <S>, then why remove
>> the <S>? I thought it was removed due to the compiler being unable to
>> infer <S> in lambdas and method references. If we'll have to specify
>> types in those situations anyway, that explanation no longer makes
> I believe we are talking about two different methods - thenComparing used to
> be less problematic as it was changed (as you say) not be be a generic
> method, so that problems with stuck lambdas/overloaded method references
> were no longer biting. Since thenComparing is also not overloaded, I don't
> see any problem in using this method with the simplified approach too.
Ah, now I understand.
Comparator<String> c = Comparator
.comparing((String x) -> x.length())
.thenComparing(x -> x.length());
That compiles with the current signatures, but not with the <S extends
T> signatures. Looks like I was confusing issues after all. You
weren't saying the "thenComparing" line above will stop working (with
the current signatures).
More information about the lambda-spec-observers