function overload on full signature?

[Sönke Ludwig]

Am 15.11.2012 22:05, schrieb Timon Gehr:
> On 11/15/2012 07:09 PM, Sönke Ludwig wrote:
>> Am 14.11.2012 20:07, schrieb Timon Gehr:
>>> On 11/14/2012 06:30 PM, Rob T wrote:
>>>> On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright wrote:
>>>>>> I'm not requesting this to be a feature of D, I'm only asking why it
>>>>>> is not
>>>>>> being done.
>>>>>
>>>>> Because types are resolved bottom-up, and if the return type were part
>>>>> of the overloading, there would be no sensible rule to determine the
>>>>> types.
>>>>
>>>> But doesn't the compiler already have to perform overload-like decision
>>>> making on return types in the "alias this" case, esp once multiple
>>>> conversions are allowed?
>>>>
>>>> class A{
>>>>     int i;
>>>>     bool b;
>>>>     alias i this;
>>>>     alias b this;
>>>> }
>>>>
>>>> main()
>>>> {
>>>>     auto a = new A;
>>>>     int i = a;
>>>>     bool b = a;
>>>> }
>>>>
>>>> --rt
>>>
>>> alias this is not the best example, but the necessary logic is basically already in the compiler.
>>> Lambda parameter type deduction based on the expected type is a similar task.
>>>
>>> It is not being done because it is not being done. Full type inference would be even more fun.
>>
>> In the lambda case it's return type deduction and not overload resolution. Those are actually two
>> very different things.
>>
> 
> Yes, lambda _return_ type deduction is less related, but I have never claimed otherwise.
> 
> Another case that shows how a compiler must be able to take into account the left hand side of an
> assignment in order to type check the right hand side:
> 
> int foo(int);
> double foo(int);
> 
> void main(){
>     double function(int) fun = &foo;
> }

The point I was trying to make is that taking the LHS into account is one thing (be it return type
or parameter type deduction). But selecting the right overload in presence of implicit type
conversions is much more than that and brings a lot of problems. In particular I suspect that a
solution could either be to flag every possible ambiguity as an error and thus possibly make
resulting APIs badly usable, or to define resolution rules to at least handle some ambiguities but
in turn make it difficult and non-obvious for the programmer what happens.

There can also be hidden ambiguities with number literals or custom operator overloads, things that
are solvable but all add up.

But then again I don't really have concrete use cases that I can think of, so maybe in real cases it
would not matter anyway and going with the always-error-out route would be fine.