Overload Ambiguity

[Zhong Yu]

Thanks Dan, the overloading resolution is really powerful stuff. It
solves two use cases that have been bothering me:

1. Returning Void

Say we have a method

    <U> then(T->U)

it's a little inconvenient if caller intends U=Void, because he has to
return something:

    then(x->{ return null; })

Now we can add an overloaded version

    then(T->void)

    then(x->{});

2. Flat Map

Wouldn't it be nice if we can overload

    interface Foo<T>

        <R> Foo<U> map( Function<T, U> );
        <R> Foo<U> map( Function<T, Foo<U>> );  // AKA "flat map"

The first problem is erasure, we cannot have two map(Function). But we
can add another Function-ish type, and overloading now works.

    /** same as Function; provided for some method overloading cases
    interface _Function<T,U> extends Function<T,U>{}

I don't think it'll cause any problem for API users; they'll rarely
need to reference _Function by name.

This means we can implement the so called "Promise/A+" interface in Java

    interface Promise<T>

        <U> Promise<U> then(Function<T, U> onSuccess);

        <U> Promise<U> then(Function<T, U> onSuccess,
                                             Function<Exception, U> onFailure);

        <U> Promise<U> then(_Function<T, Promise<U>> onSuccess);

        <U> Promise<U> then(_Function<T, Promise<U>> onSuccess,
                                             _Function<Exception,
Promise<U>> onFailure);


Zhong Yu