1

In C++, Why function overloading not implemented on the basis of return type?

Dew
  • 2,993
  • 5
  • 17
  • 7
  • This used to be a good question once, but now it's just yet another duplicate: http://stackoverflow.com/questions/442026/function-overloading-by-return-type – UncleBens Mar 31 '11 at 15:46

5 Answers5

15

Because it is legal to ignore return values, thus the compiler would not always be able to realistically decide which overload to invoke.

Consider

void foo();
int foo();
long foo();

...
foo(); // which function to call here???

But even if the return value is assigned, it may not be possible to choose between equivalent overloads when a conversion is required:

double d = foo(); // and here???
David Rodríguez - dribeas
  • 204,818
  • 23
  • 294
  • 489
Péter Török
  • 114,404
  • 31
  • 268
  • 329
  • 2
    And even if you store every return value: there can be an ambiguous situation if there is a type with multiple constructors involved that can be used for a conversion. – tgmath Mar 31 '11 at 10:48
  • I have an urge to downvote any answer saying it's because the compiler can't **always** choose. The compiler can't always choose between overloaded functions as it is, and that's where you get errors. - Better answer would be that this would mean very complicated rules, or providing means to make a big mess, and can be achieved with conversion operators if you really want to. – UncleBens Mar 31 '11 at 15:59
  • @UncleBens, fair enough, let's say the compiler wouldn't be able to choose in a significant portion (possibly close to majority) of cases, because return values are quite often ignored - much more often than you see an ambiguous overload on function parameters / conversions. – Péter Török Mar 31 '11 at 16:09
  • If a function was overloaded on return type, most likely this means that the result is important. There are some kinds of functions where you don't normally ignore the result and if you did, it would most likely be a coder's error - you wouldn't ignore the result of, say, `boost::lexical_cast(str)`. - However, there would indeed be lots of cases where you'd need to disambiguate explicitly, and the use cases would be very limited. So not worth the mess it would make for everyone. – UncleBens Mar 31 '11 at 18:31
1

Consider the case:

double Fun()
{
}


int Fun()
{
}

Since it's not compulsory to assign a return value from a function, a call to Fun() would be ambiguous since the compiler wont know which Fun() to call.

Shamim Hafiz - MSFT
  • 21,454
  • 43
  • 116
  • 176
1

Because C++ has implicit conversions which make it more or less impossible most of the time, e.g.:

int f();
char f();

double d = f();

It's possible to simulate overloading on the return type some of the time, by using a proxy object:

int doFInt();
char doFChar();

struct Proxy
{
    template<typename T> operator T() const
    {
        return static_cast<T>(doFInt());
    }
};
template<>
Proxy::operator char() const { return doFChar(); }

Proxy f();

double d = f();  //  Calls doFInt().

About the only time something like this is worth the bother, however, is when it can be made truely generic; something like a getAttribute function where the attribute is always stored as a string, and the generic form of the function uses boost::lexical_cast to convert to the target type.

James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • 1
    I don't think this is a very good explanation; the same thing could be said for function arguments. `void f(int) { } void f(char) { }; f(0.0);` has the same problem that your example has, but it's allowed syntactically. – tenfour Mar 31 '11 at 11:31
  • 1
    Certainly. The context isn't the same, but implicit conversions add ambiguity with regards to the arguments as well. (And during standardization, many people argued against allowing conversions when overload resolution was involved.) The question is just how much risk of ambiguity you are willing to accept. The committee drew the line where it drew it. (Also, a better example of where the return value might cause a problem is if you used it as an argument to another overloaded function.) – James Kanze Mar 31 '11 at 14:40
  • Could you explain your code a little? How would you use it to get a char? And how does that operator overloading and templating work together? – Sarien Jul 25 '12 at 06:55
  • @CorporalTouchy What don't you understand about it. It's simply a simple way of tricking the compiler into overloading on the return type. The actual function (`doFInt` or `doFChar`) isn't called until you try to convert `Proxy` into some known type. If that known type is `char`, the explicit specialization of the conversion function is used; otherwise, the template version is used. – James Kanze Jul 29 '12 at 15:30
  • I just didn't know about conversion operators so it all made very little sense to me. :) – Sarien Jul 30 '12 at 11:55
0

Because the compiler would not always been able to decide which function to select.

sergico
  • 2,595
  • 2
  • 29
  • 40
0

When calling a function, its return type is not involved. So it would be meaningless to implement function overloads with different return types.

rainshark
  • 47
  • 3
  • 10