Topics in this digest:

      1. rationale for no overloading by return type
           From: "Allan Clarke" 


________________________________________________________________________
________________________________________________________________________

Message: 1
   Date: Fri, 15 Jun 2001 07:47:12 -0500
   From: "Allan Clarke" 
Subject: rationale for no overloading by return type

(Source: comp.lang.c++, 12 Jun 2001)

ABERG: haberg@matematik.su.se (Hans Aberg)

> I am not sure what you mean: It is already causing a problem for
> compilers. The problems will grow worse with more complicated example
> expressions, resulting in a slow compiler.


STRUSTRUP: "Bjarne Stroustrup" 

At worst, the compiler will be ever so slightly slower handling really
complicated expressions. Such code would constitute far less than a
thousands of the text of a realistic program, more likely less than a
millionth.

ABERG:

> I think that finding a good implementation for a full scale 
overloading by
> return type will be a problem, as one will have to combine type 
inference
> from the two ends of the expression type tree.

STRUSTRUP:

Good algorithms for that have been known for at least 20 years. Look at
the Ada implementation literature. In particular, look for something 
called
"the yo-yo algorithm".

The reason that C++ doesn't support overloading based on the return 
type
is not that I didn't know how to implement it or that I feared 
compile-time
overheads. The reason is that I was confident that often the results 
would be
incomprehensible to programmers, and specifically that I wanted to 
preserve
the nice property that the meaning of expressions can be determined 
from
the bottom up. For example, once you know the types of x and y, the 
legality
and meaning (if any) of x+y can be determined.

I still think that the advantages of *not* overloading on the return 
type
outweighs the advantages of overloading on the return type.