Karl Keyte <KKEYTE@ESOC.BITNET> writes:

>Why can't we overload functions by return type only?  I can see if I had
>two functions such as:

>   int myPrint(void);
>& long myPrint(void);

>then it would be ambiguous to do something like:

>       myPrint();

>but that shouldn't be a problem - the compiler should generate an error.
>Type promotion could also be solved.  Something like:

>     int status;
>     status = myPrint();

>sould call the 'int' variety.  The usual type conversion rules should
>apply with any ambiguities being reported by the compiler as an error.

>Backwards compatibility is also guaranteed as it is currently not
>possible to overload by return type, so calls such as:

>      free(myPointer);

>would only BECOME invalid if the user overloaded the function with
>another using the same parameter list.

>I'd like this facility, I think it fits naturally with the language and
>I think it's probably only because of the compiler writing complexities
>that it's not available already.

Maybe it is because the necessity to parse an expression both inward
to outward, and outward to inward (for return type checking) at the
same time, and resolve on an unambigous resolution, a thing a compiler
MIGHT be capable of iff he employed VERY complicated algorithms,
but a human very well might not, when conversions are concerned as
well. It is hard enough keeping track of all the rules when analyzing
an expression from the core to the outer levels, it would surely be
hell, if you had to coordinate this back again with the possible
conversions to outer type again.

This rationale is explained in ARM as well. Did you care to read before
posting? If you did, why were you not concerned with that argument?
If you did not, well...
--
 David Kastrup        dak@messua.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, W-5100 Aachen, Germany

Karl Keyte <KKEYTE@ESOC.BITNET> writes:

>Why can't we overload functions by return type only?  I can see if I had
>two functions such as:

>   int myPrint(void);
>& long myPrint(void);

>then it would be ambiguous to do something like:

>       myPrint();

>but that shouldn't be a problem - the compiler should generate an error.
>Type promotion could also be solved.  Something like:

>     int status;
>     status = myPrint();

>sould call the 'int' variety.  The usual type conversion rules should
>apply with any ambiguities being reported by the compiler as an error.


I believe this is discussed in the ARM.

It would be possible, but the opportunities for ambiguity are
larger than you may realize.  For example:
 int foo();
 long foo();
 short bar();
 double bar();

 float x = foo() + bar(); // which foo? which bar?

The compiler (and human code reader) must be prepared to deal with
many functions in one expression each overloaded on return type and
try to figure out whether the expression is ambiguous.  It was judged
the complications were not worth the benefits.

Personally, I think C++ has enough uncertainties and ambiguities
without looking for ways to add more.
--

Steve Clamage, TauMetric Corp, steve@taumet.com

In article <dak.730861242@messua> dak@messua.informatik.rwth-aachen.de (David Kastrup) writes:
>Karl Keyte <KKEYTE@ESOC.BITNET> writes:
>
>>Why can't we overload functions by return type only?  I can see if I had
>>two functions such as:
>
>>   int myPrint(void);
>>& long myPrint(void);
>
>Maybe it is because the necessity to parse an expression both inward
>to outward, and outward to inward (for return type checking) at the
>same time, and resolve on an unambigous resolution, a thing a compiler
>MIGHT be capable of iff he employed VERY complicated algorithms,
>but a human very well might not, when conversions are concerned as
>well.

 Yes. Although the algorithm is not that complicated,
it could be very slow. I think Ada allows overloading on
return types. (But it disallows automatic conversions to make up for that).

>It is hard enough keeping track of all the rules when analyzing
>an expression from the core to the outer levels, it would surely be
>hell, if you had to coordinate this back again with the possible
>conversions to outer type again.

 Yes, however there already IS an element of this with
user defined operators. They already require some degree
of 'inward/outward' parsing.

>
>This rationale is explained in ARM as well. Did you care to read before
>posting? If you did, why were you not concerned with that argument?
>If you did not, well...

 The question might be why the argument does not
apply to user defined operators. You cant have

 int f();
 long f();.

But you *can* have

 class Number {
  long x;
 public:
  operator int() {return x;}
  operator long() {return x;}
 }

 X f();

which, while not quite the same, does introduce similar problems.

--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
 Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------

Why can't we overload functions by return type only?  I can see if I had
two functions such as:

   int myPrint(void);
& long myPrint(void);

then it would be ambiguous to do something like:

       myPrint();

but that shouldn't be a problem - the compiler should generate an error.
Type promotion could also be solved.  Something like:

     int status;
     status = myPrint();

sould call the 'int' variety.  The usual type conversion rules should
apply with any ambiguities being reported by the compiler as an error.

Backwards compatibility is also guaranteed as it is currently not
possible to overload by return type, so calls such as:

      free(myPointer);

would only BECOME invalid if the user overloaded the function with
another using the same parameter list.

I'd like this facility, I think it fits naturally with the language and
I think it's probably only because of the compiler writing complexities
that it's not available already.

Regards,

========================================================================
Karl Keyte                                      Phone: +(49) 6151 902041
European Space Operations Centre                  Fax: +(49) 6151 904041
Robert-Bosch Strasse 5, D-6100 Darmstadt, Germany
========================================================================