At 15:02 +1000 1999/05/20, Fergus Henderson wrote:
>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.
So one realizes quickly that a sophisticated language should not have a lot
of implicit type conversions, as it makes you loose control over the
semantic subtleties.
>> 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.
Well, the reason I discovered this feature was that it would have allowed
me to implement tail-recursive evaluator type of jump to a function in a
language transparent way. That is, when writing A g(B) { ... return f(x);
}, instead of first computing f(x) and returning the value, one returns the
pair (f, x) to an evaluator mechanism which evaluates f(x) after g has
terminated. Thus the effect is that of a jump from g to the computation of
f(x).
Functional languages such as Scheme, SML, and Haskell of course has such a
mechanism built into the language, so it is good to be able to do that in
C++.
However, due to the implicit construction of the void f(B) function, that
is not possible in C++. Instead one must introduce a special operator
handling those jumps to a function. This unnecessarily puts the burden on
the user of keeping track of it.
I do not think there is any controversial about calling these facts a flaw
in C++, because C++ inherited this from the requirement of compatibility
with C.
In functional languages, such as Haskell then, one simply avoids
(conflicting) implicit type conversions because there is no C one is forced
to be compatible with.
So certainly, the type mechanism of a computer language should be able to
recognize and give control to the distinction between A f(B) and void f(B),
and it should not impose implicit type conversions causing type conflicts
which cannot be resolved.
Hans Aberg
* Email: Hans Aberg <mailto:[EMAIL PROTECTED]>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
