overload patterns/anti-patterns

[Brian Goetz]

>> ... where the function types have the same arity.
>
> .. of arguments. The "x -> foo()" vs "x -> { foo(); }"
> issue (and variants) ambiguate cases of no result vs a result.

Right.  We discussed this at the EG meeting and the consensus was to 
coerce non-void to void if the only overload candidate was void (to 
allow cases like forEach(list::add), but to declare ambiguity if there 
is both a void and a non-void option.

>> Similarly, it is a key goal to make overloading on specialized return
>> type safe,
>
> Modulo the above? Or is this an important enough goal to require
> that void actions use braces?

We initially tried that -- and people *hated* it.  Having to say

   forEach(e -> { list.add(e); })
instead of
   forEach(e -> list.add(e))

really, really bothered people.

The "overload on specialized return type" is only about boxed vs 
unboxed, not about void vs value.  If there are conflicting overloads of 
void vs value for the same arity, you'll be disambiguating.

Similarly, if there are conflicting overloads on parameter types, you'll 
be disambiguating.