Overload resolution simplification
maurizio.cimadamore at oracle.com
Wed Aug 14 02:57:10 PDT 2013
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#.
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 126.96.36.199 and 188.8.131.52). 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
More information about the lambda-spec-observers