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

[Mike Parker via Digitalmars-d-learn]

On Saturday, 20 February 2016 at 15:47:27 UTC, Jeremy DeHaan 
wrote:

> 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.

auto is not the only potential ambiguity. Consider:

getValue();

It's not unusual to discard the return value when calling a 
function. Though a getter isn't a good example of this, of course.

Another. How would you reliably do compile-time reflection if 
this were allowed? If you need to use it in a template to declare 
a variable of the type returned by foofunc, but there are two 
different return types for foofunc, then what do you do?

>
> 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.

This would create special cases, where a function call succeeds 
based on context. That seems to me to be something that would a) 
break expectations and b) be a tremendous inconsistency.