Why does partial ordering of overloaded functions not take return type into account?

[Jeremy DeHaan via Digitalmars-d-learn]

On Saturday, 20 February 2016 at 12:29:21 UTC, Jonathan M Davis 
wrote:
> On Saturday, February 20, 2016 03:24:45 Jeremy DeHaan via 
> Digitalmars-d-learn wrote:
>> 
>> snip
>
> I'm unaware of any language that takes the return type into 
> account when overloading. The type the expression test.thing() 
> has to be determined before the assignment is evaluated, and it 
> would be very confusing if the return type were used for 
> overload evaluation in a context like this, because there are 
> other contexts where it would be impossible to do that even 
> theoretically - the simplest being
>
> auto thingOne = test.thing();
>
> So, suddenly, which function gets called would depend on where 
> the expression was used, which would just be confusing and 
> error-prone.
>
> - Jonathan M Davis

With the case of auto of course there is ambiguity, you don't 
know which one to pick. In my example there should have been no 
ambiguity at all as only one of the overloads would actually 
compile. That is what confuses me and why I think return type 
should be taken into account.

If there are multiple overloads that have the same number of 
parameters, a very simple addition to the rules of function 
overloading would be "does it compile?" If only one overload 
compiles, use it. If more than one compile, there is ambiguity 
and its an error.