function overload on full signature?

[Rob T]

On Thursday, 15 November 2012 at 17:33:24 UTC, monarch_dodra 
wrote:
> I'd say because overall, you gain *very* little out of it, and 
> it costs you much more complex compiler rules.
>

But how little, and for how much extra cost? Overloading already 
has a cost to it, and it's really difficult for me to understand 
why adding return type to the mix has to be be many times more 
costly. I will confess that I'm not a compiler designer, but I 
can still try to imagine what would be needed. Already the 
compiler MUST ensure that the return type is valid, so we're 
essentially already there from what I can see.

> Most of all though, I'd say it is a bad idea in and out of 
> itself: If you overload on the return type, you open the 
> floodgates to call ambiguity.

Sure, but not much more so that we have already with the current 
overloading system, and the compiler can certainly prevent an 
invalid compile from happening when there is even a hint of 
ambiguity, as it does already with current overloading. Besides I 
would expect such a feature to be used by advanced programmers 
who know what they are doing because overloading in general is an 
advanced feature and it is certainly not for the easily confused.

> I mean, are there even any real use-cases for overload on 
> return type?

Yes, I've wanted this for a few years, and I have used a similar 
feature successfully through C++ class operator conversions.

I brought up the example of operator conversion for classes in 
C++. I know some of you have said it's not the same thing, but 
IMO it is the same thing.

int x = a;
string y = a;

Does "a" represent a class or a function? Why should it matter?

class A
{
    int i;
    string s;
    alias i this;
    alias s this; // ouch D does not allow it!
    ...
}

UFCS

int convert( A a )
{
    return a.i;
}

string convert( A a )
{
    return a.s;
}

int i = a.convert;
string s = a.convert;

A real-world use case example is to implement Variant types more 
naturally, where you could do the above and have it convert to 
int or string (and other types) on demand depending on the 
validity of data type. Obviously it will run-time error when the 
type cannot be converted, or perform whatever logic the 
programmer desires.

--rt