Overload resolution simplification

Michael Hixson 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
>> sense.
> 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.
> Maurizio

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 mailing list