digitalmars.D - Overload by return type
- dsimcha (4/4) Jan 13 2009 Just curious, why doesn't D, and why don't more statically typed languag...
- John Reimer (7/13) Jan 13 2009 He he... well, there has certainly been some discussion about it here. ;...
- BCS (14/20) Jan 13 2009 Off hand it's one more degree of freedom (and confusion) in trying to fi...
- Tim M (4/11) Jan 13 2009 Templates kind of give you that sort of power. If you weren't taking the...
- Peter C. Chapin (18/22) Jan 15 2009 Ada allows overloading on return type. I think it can get away with it
- Kagamin (3/31) Jan 22 2009 Fortunately, D already has this bug
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
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
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
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
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
BCS Wrote:Hello dsimcha,Fortunately, D already has this bug http://d.puremagic.com/issues/show_bug.cgi?id=52Just 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 22 2009