Overload resolution simplification

[Maurizio Cimadamore]

On 13/08/13 23:11, Ali Ebrahimi wrote:
> C# is most similar language to java. C# supports Overloading and type
> inference among many other things. So why java can not support them. May be
> we need learn from C#.
Hi Ali,
yes C# and Java are similar. But overloading is slightly different. For 
instance, C# does speculative type-checking of lambda bodies, and treats 
errors during a speculative check as a failure in method applicability. 
This was considered (unanimously?) unacceptable by the EG as too brittle 
(i.e. subtle changes to lambda body - or to methods referenced by the 
body - could trigger change in outer overload selection). So I believe 
that means going down there doesn't seem to be an option.

I also believe (but I need Neal's help here as I'm no C# guru) that C# 
behaves very differently in the distinction between overload and 
inference; Java does a first pass of overload in which information from 
target type is not taken into account. Then there's a second round 
(after most specific method has been selected) in which target-type is 
injected, mostly for the purpose of inferring a better type (in the 
'old' JLS SE 7, this used to be 15.12.2.7 and 15.12.2.8). I believe C# 
is the exact reverse of this - it does inference first, to get 
type-parameters out of the way (meaning that members for which inference 
fails will be exclude from set of applicable candidates) then it will do 
method selection on fully instantiated signature. This has subtle 
consequences that makes it harder to make a 1-1 comparison - but it 
would seems that C# can use the target-type information _ahead_ of 
overload resolution to perform inference, thus being able to reject 
applicable candidates based on return mismatch (which Java cannot do).

Last but not least, C# has a uniform treatment for primitive vs. 
generics - which means it simply won't need to amount of overloads that 
are common in the Stream API. So, again, it's hard to see whether how 
the expressive power of the two scheme can be compared because, on 
average, I have the feeling that C# users to rely less heavily on 
primitive overloads - which means most of the problems discussed here 
won't even apply to C# (again, Neal please chime in :-)).

Comparing languages is good - sometimes you can learn a lot; I believe 
we improved the syntax a lot when we decided to make it similar to C# 
and Scala. But other areas, like overload resolution and inference, 
while they seem very similar, can hide subtle differences that make 
impractical to just copy and paste feature from one language onto 
another. Java has its own bag of constraints that will require its own 
dedicated solution.

Maurizio