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

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, February 20, 2016 03:24:45 Jeremy DeHaan via Digitalmars-d-learn wrote:
> module main;
>
> struct ThingOne
> {
>   int thing = 1;
> }
>
> struct ThingTwo
> {
>       float thing = 2;
> }
>
>
> struct Test
> {
>    ThingOne thing()
>       {
>        return ThingOne();
>   }
>
>   ThingTwo thing()
>   {
>       return ThingTwo();
>   }
>
> }
>
>
> void main()
> {
>   Test test;
>
>   ThingOne thingOne = test.thing();
> }
>
>
> test.d(35): Error: main.Test.thing called with argument types ()
> matches both:
> test.d(17):     main.Test.thing()
> and:
> test.d(22):     main.Test.thing()
>
> Why isn't the return type checked when resolving this? Only one
> of the choices would actually compile so there should be no
> ambiguity.

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