www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Overload by return type

reply dsimcha <dsimcha yahoo.com> writes:
Just curious, why doesn't D, and why don't more statically typed languages in
general, support overload by return type?  I haven't exactly thought through
all the pros and cons, but at first glance it seems like an incredibly useful
thing.  What's the catch that I'm missing?
Jan 13 2009
next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello dsimcha,


 Just curious, why doesn't D, and why don't more statically typed
 languages in general, support overload by return type?  I haven't
 exactly thought through all the pros and cons, but at first glance it
 seems like an incredibly useful thing.  What's the catch that I'm
 missing?
 



He he... well, there has certainly been some discussion about it here. ;-D

A little bit of googling:

http://www.digitalmars.com/d/archives/digitalmars/D/23835.html

It's been discussed also throughout many other posts on and off the topic. 

Lots of fun... :)

-JJR
Jan 13 2009
prev sibling next sibling parent BCS <none anon.com> writes:
Hello dsimcha,


 Just curious, why doesn't D, and why don't more statically typed
 languages in general, support overload by return type?  I haven't
 exactly thought through all the pros and cons, but at first glance it
 seems like an incredibly useful thing.  What's the catch that I'm
 missing?
 


Off hand it's one more degree of freedom (and confusion) in trying to figure 
out what type something is.

int bar(char[] c)
int[] bar(char[] c)

float baz(int i)
object baz(int[] i)

auto z = baz(bar("what type is z"));

float foo();
object foo();

z = foo();  // what foo?


of an expression is not dependent on what expression it is nested under. 
Changing this could have far reaching consequences.
Jan 13 2009
prev sibling next sibling parent "Tim M" <a b.com> writes:
On Wed, 14 Jan 2009 18:31:53 +1300, dsimcha <dsimcha yahoo.com> wrote:


 Just curious, why doesn't D, and why don't more statically typed  
 languages in
 general, support overload by return type?  I haven't exactly thought  
 through
 all the pros and cons, but at first glance it seems like an incredibly  
 useful
 thing.  What's the catch that I'm missing?



Templates kind of give you that sort of power. If you weren't taking the  
return value then it wouldn't work without some extra rules. I think  
opCast should be changed to allow unlimited availables casts.
Jan 13 2009
prev sibling next sibling parent "Peter C. Chapin" <pcc482719 gmail.com> writes:
dsimcha wrote:


 Just curious, why doesn't D, and why don't more statically typed languages in
 general, support overload by return type?  I haven't exactly thought through
 all the pros and cons, but at first glance it seems like an incredibly useful
 thing.  What's the catch that I'm missing?


Ada allows overloading on return type. I think it can get away with it
because it does not allow any (hardly any) implicit type conversions.
Thus there is a great reduction in the complexity of the overload
resolution rules. That is, overload resolution in complicated
expressions is simplified because there are no implicit type conversions
 in the mix. As a small example:

procedure P(X : Integer);
function F(X : Integer) return Integer;
function F(X : Integer) return Float;

...

P(F(1));

The above can only mean a call of F returning Integer being passed to P
taking Integer since there is no way to use Float as an argument to P.
Of course ambiguities, when they arise, are flagged as errors as you
would expect. However, ambiguous situations don't arise as often as they
might because of the lack of implicit conversions.

Peter
Jan 15 2009
prev sibling parent Kagamin <spam here.lot> writes:
BCS Wrote:


 Hello dsimcha,
 

 Just curious, why doesn't D, and why don't more statically typed
 languages in general, support overload by return type?  I haven't
 exactly thought through all the pros and cons, but at first glance it
 seems like an incredibly useful thing.  What's the catch that I'm
 missing?
 


 
 Off hand it's one more degree of freedom (and confusion) in trying to figure 
 out what type something is.
 
 int bar(char[] c)
 int[] bar(char[] c)
 
 float baz(int i)
 object baz(int[] i)
 
 auto z = baz(bar("what type is z"));
 
 float foo();
 object foo();
 
 z = foo();  // what foo?
 

 of an expression is not dependent on what expression it is nested under. 
 Changing this could have far reaching consequences. 


Fortunately, D already has this bug
http://d.puremagic.com/issues/show_bug.cgi?id=52
Jan 22 2009