On 19-May-1999, Hans Aberg <[EMAIL PROTECTED]> wrote:
> At 09:36 +0100 1999/05/19, D. Tweed wrote:
> >What I've always understood as the main argument for not allowing
> >overloading by return value still applies in a weaker form in Haskell,
> >namely:
> >
> >int f(int a) & double f(int a) can't be resolved by the return value in
> >C++ because it's legal (& for an imperative language, sometimes sensible)
> >to call just f(5), the compiler automatically throwing away the return
> >value. For a pure function clearly this is meaningless since the only
> >effect of the function is to return a value.
C++'s imperative nature is *not* the reason why that kind of overloading
is not allowed in C++. Indeed Ada, which is also an imperative language,
does allow overloading on the return type.
The reason that C++ doesn't allow overloading on the return type is that
this feature was seen as being too complex to implement. The complexity
is high mainly because C++ allows implicit type conversions, and this
interacts badly with overloading on the return type. (Another minor
reason why the complexity is worse is that C++ does not have type
inference -- if you have type inference already, then allowing
overloading on return types doesn't add as much additional complexity).
> What is a feature of C++ is in fact also a flaw:
>
> The proper view (I think) of the fact that one is not forced to take care
> of return values is that together with a function of type A f(B),
> implicitly also a function of type void f(B) is created.
I think that is a silly way of viewing things -- it makes things more
complex, and it doesn't gain you anything.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
