Overload resolution simplification

[Michael Hixson]

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

Thanks.

-Michael