C++ Name Mangling

[mangosteen]

Why are return types not included in compiler generated mangled names?

[laserlight]

I have not studied the topic of how compilers implement name mangling, but my guess is that this is because the return type is not involved in overloading, so the implementer did not see fit to include it.

[JVene]

Name mangling is about identifying each unique member function. Since functions within a class can't be overloaded such that they differ only by return type, the return type isn't needed as part of the "key" to differentiating between functions. It would be unnecessary space occupied by the "key" value created by the mangled name.

[mangosteen]

Thank you both. I guess my question is really why does the language disallow overloading on return type? I understand that we can't overload functions based purely on return type because return type is not part of the mangled name -- but what was the basis for that decision?

[JVene]

I'm sure there are more reasons than occur to me, but here are a few....

If we had:

float func();
double func();
anyobject func();


How do we select based on, say....

func();

...it's always reasonably permissible to ignore the return type, it's not required.


int i = func();

Obviously there are other similar issues when passing types which require conversion to make a selection, and similar ambiguity is found there, too.


someotherobject b;

b = func();

...obviously there wouldn't be a selection, but would this always be so?

What if someotherobject had a copy and assignment to float, or anyobject?


The mechanism is also illogical. A function is theoretically called before the return is prepared. The logical grouping of these concepts is that of a sequence of steps, not of a unified step, and it isn't reasonable to make the assumption.

func( b );
func( otherfunc() );

The logical grouping of func and b or otherfunc happens at one sequence step. It's true that otherfunc must be called first, and it's return is in the 'position' of b in this logical sequence once that return is completed.

Imagine the side effects of having to be carful about what version of otherfunc might be called based on the type of the parameter func required.

This would create a range of complicated, hidden interactions in code that would lead to bugs, but then we can already have such arguments about overloaded functions differentiated by parameter.



I don't recall reading the final determining reason which made the point otherwise inarguable, such musings are for the PhD's who focus on creating languages. I think, among them...

void func();
int func();


func();

It would not be possible to select void func and still support the notion of calling a function without regard to the return type.


int * func();
int & func();
int func();

It's reasonable to allow these different types for parameters to a function, but what about return?

a = b + func();

...reference or value?



It think, too, one of the guiding principles was to avoid adding features which had reasonable alternatives, so as to avoid mission creep in designing the language, and bloating the complexity of the language (which is unavoidable, though it can be minimized).

Since selection of values intended for use in the calling code can be obtained through passing via reference, the need for the feature of selection by return type alone is hard to justify in the face of any ambiguities it may impose. The balance of these issues may have been the deciding factor.

[mangosteen]

Thanks JVene. That makes sense.