Stream.flatMap reference ambiguity

[Zhong Yu]

On Tue, Feb 26, 2013 at 6:23 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> On Feb 26, 2013, at 2:57 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>
>>> I think the core problem is the API (in general, it's best to avoid overloading with functional interfaces that have different parameter types),
>>
>> I don't quite understand what you mean, can you clarify?
>
> The type of the second parameter of the lambda depends on the overload resolution choice -- it may be a Consumer<String>, or a IntConsumer, or a LongConsumer, or a DoubleConsumer.  So overload resolution is given four different possible typings of the parameters of the lambda, and is asked to choose the "best" one.
>
> As I've pointed out, this is a pretty brittle situation, and while the compiler is able to do a certain degree of disambiguation, there's a good chance that clients of the API will encounter ambiguities.
>
> For example:
>
> stream.flatMap((x, sink) -> sink.accept(x.length()));
>
> 'x.length()' is an int, meaning the intent is probably to represent an IntConsumer; but the compiler is not equipped to make that sort of judgement, and would be equally happy with a LongConsumer, or a DoubleConsumer, or a Consumer<Integer>, ...
>
> Hence, API designers should generally avoid overloading that relies on disambiguating between functional interfaces of the same arity that have different parameter types.

What I'm confused about is that the sentence sounds like it's ok to
overload with functional interfaces that have _same_ parameter types.
Or is that just outright nonsense? So did you simply mean "no overload
with functional interfaces of the same arity"?

Zhong Yu