TITLE: Arguments against overloading based upon return type


PROBLEM: hartman@ulogic.UUCP (Richard M. Hartman)

The real question is why in an UNambiguous situation like:

	char *p;
	int i;

	i = o.get(1,2);
	p = o.get(3,4);

overloading on return type is not allowed.  Sure it creates
an ambiguous situation if you are not using the return type.
But as you pointed out, that can be resolved w/ a cast.


RESPONSE: clamage@taumet.Eng.Sun.COM (Steve Clamage)

Whether to allow overloading on return types was a C++ design issue,
as noted in the ARM and elsewhere. Algol-68, for example, allows it,
so it is not strictly a feasibility issue.

The rules for resolving overloaded functions have gone through several
cycles of explanation and review. The ARM takes about a dozen pages to
explain them fully, and that is a somewhat compressed discussion.
I have never heard of anyone who thought the rules were too simple,
and most people find them too complex as it is. Most compilers do 
not implement the rules exactly right, due to their complexity.

All this WITHOUT allowing overloading on return type. If we added
overloading on return type, the rules would be much more complex,
and opportunities for ambiguity would be increased.

It is not true that that ambiguous situations occur only if you
don't use the return type. Consider this:

int f(int);
int f(double);	// overloaded only on parameter type

int g();
double g();	// overloaded on return type

f( g() );	// use return type of g()

There is no way to decide which g (and consequently which f) to use.
Similarly, consider
	float x = g() + g();

Finally, the rules in C and C++ for expression evaluation do not take into
account the surrounding context. For example:
	int i, j;
	double x = i + j;
The subexpression "i+j" must be evaluated as integer addition, even
if that would overflow. That the result will be converted to double
and early conversion would avoid overflow is not relevent. This
simplifies language translation, and more importantly, simplifies
interpretation by humans of source code. When you see "i+j", you
know the result is an int.

The suggestions on this thread would require analysis of context to
determine expression types. Saying "use a cast" does not change this.
For example (typeA)(expr) under current rules evaluates "expr", then
converts the result to "typeA". The suggested changes require pushing
the cast down into the expression as part of the evaluation.

The result makes programs harder for humans to understand, and makes
compilers much more complicated. The examples shown are always quite simple,
but when you analyze a proposed language rule, you have to look at non-
simple cases too. More complicated expressions can become quite intractable.