Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!kth!draken!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.c++
Subject: Re: Arguments to Overloaded Operators
Message-ID: <868@tukki.jyu.fi>
Date: 9 Jun 89 07:59:44 GMT
References: <11032@orstcs.CS.ORST.EDU> <1100@cadillac.CAD.MCC.COM> <238@pink.ACA.MCC.COM>
Reply-To: markku@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 57

In article <238@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette) writes:
>In article <1100@cadillac.CAD.MCC.COM> vaughan@mcc.com (Paul Vaughan) writes:
>>Two questions:
>>1)
>>Has anyone considered overloaded functions/operators that are selected
>>not only by a match of parameter types, but also according to the
>>return type needed in the context?  That is, have multiple
>>definitions for the same function name with differing return types.
>>Forgive me if this has been beaten to death before.
>
>Forgive me also!  I have been meaning to ask about this for quite awhile
>now.
>
>I have heard that Bjarne had *some* good reason for not allowing overloading
>based on return types, but I never actually found out what that reason was.
>
>Perhaps Andrew or Bjarne will clarify this for us.  If they do, I hope that
>they will not be shy of details.  I really want to fully understand the
>reason for this choice, right down to the nitty-gritty compiler-implementation
>details.

I think there is a plausible fundamental reason, independent of compiler
implementation (although omitting this kind of overloading obviously
makes the compiler writer's job a little easier, too).

In C++ expressions, the context of each subexpression (e.g. a function
invocation) in general only weakly determines the expected type of
the subexpression. This is in part caused by the automatic type conversions,
of which there are too many to my personal liking. One example of these
is the widening of char values to int in many contexts: it even prevents us
from declaring an overloaded function pair corresponding to the _argument_
types char and int.

The automatic type conversions would be most problematic in the following case:
no overloaded function matches the expected type exactly, but more than
one of them would qualify for automatic conversion. Say, you have functions
returning short and unsigned but the context requires a long value -
which one should the compiler choose? If you think you have a logical
answer to this, let's make it a bit more difficult: the required value
is of class type, say Pet, and the overloaded functions return values of other
class types, say Dog and Cat, both of which can be automatically converted
to Pet.

Of course, there would be even situations where there is no cue at all to
which overloaded alternative is appropriate, e.g.
   (void) juggle (a, b, c);

If overloading based on return type were to be introduced,
then compilers should issue at least warnings at every place where
the choice is ambiguous. I am afraid that one would be obliged to
use a lot of explicit type casts, and the convenience of the feature
would thus sometimes be questionable. - However, there certainly are
cases in which the facility would be very nice to have.

Markku Sakkinen
Department of Computer Science, University of Jyvaskyla
(try to imagine umlauts on those a's)