www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - function overload on full signature?

reply "Rob T" <rob ucora.com> writes:
I'm wondering why overloading has been implemented to only match 
on the argument list rather than the full signature which 
includes the return type? I know I would use it if it was 
available.

I'm not requesting this to be a feature of D, I'm only asking why 
it is not being done.

--rt
Nov 13 2012
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
 I'm wondering why overloading has been implemented to only 
 match on the argument list rather than the full signature which 
 includes the return type? I know I would use it if it was 
 available.

If it worked on return type, how would it decide the overload? int foo() { ... } string foo() { ... } void bar(int x) { ... } void bar(string y) { ... } auto z = foo(); // what foo? bar(foo()); // what foo?
Nov 13 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-14 07:52, Rob T wrote:

 Is there anything like C++ conversion operators in D? I have used
 conversion ops in C++ and may want to use a similar feature in D if
 available.

There's "alias this", but you can currently only do one conversion for a given type. -- /Jacob Carlborg
Nov 13 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Tuesday, 13 November 2012 at 21:37:38 UTC, Peter Alexander 
wrote:
 On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
 I'm wondering why overloading has been implemented to only 
 match on the argument list rather than the full signature 
 which includes the return type? I know I would use it if it 
 was available.

If it worked on return type, how would it decide the overload? int foo() { ... } string foo() { ... } void bar(int x) { ... } void bar(string y) { ... } auto z = foo(); // what foo? bar(foo()); // what foo?

Don't use auto in such cases. If the compiler cannot resolve ambiguity, it will issue an error telling you that you must resolve the situation with explicit typing. I don't see a problem, because this is similar to the situation we already have when you err and create two functions with the same argument sig, the compiler cannot tell which function to use and issues an error with appropriate message. --rt
Nov 13 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, November 13, 2012 22:37:37 Peter Alexander wrote:
 On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
 I'm wondering why overloading has been implemented to only
 match on the argument list rather than the full signature which
 includes the return type? I know I would use it if it was
 available.

If it worked on return type, how would it decide the overload? int foo() { ... } string foo() { ... } void bar(int x) { ... } void bar(string y) { ... } auto z = foo(); // what foo? bar(foo()); // what foo?

It would also screw up covariant return types if overloading too the return type into account. I believe that the _big_ reason though is simply because the type of the expression is determined by the return type, not what it's assigned to. For instance, with how the language works, the type of the right- hand side of an assignment must always be determined independently of the type on the left, so the type of the expression on the right-hand side cannot depend on the type of the left. I suspect that it would complicate things considerably to try and make the return type have anything to do with function overloading. I'm sure that you could find it being discussions on it somewhere online for other C-based laguages though. Regardless, I've never even heard of a language which tried to include the return type in overload resolution. It sounds like a huge complication to me. - Jonathan M Davis
Nov 13 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 02:01:56 UTC, Jonathan M Davis 
wrote:
 It would also screw up covariant return types if overloading 
 too the return
 type into account. I believe that the _big_ reason though is 
 simply because
 the type of the expression is determined by the return type, 
 not what it's
 assigned to. For instance, with how the language works, the 
 type of the right-
 hand side of an assignment must always be determined 
 independently of the type
 on the left, so the type of the expression on the right-hand 
 side cannot
 depend on the type of the left. I suspect that it would 
 complicate things
 considerably to try and make the return type have anything to 
 do with function
 overloading. I'm sure that you could find it being discussions 
 on it somewhere
 online for other C-based laguages though.

 Regardless, I've never even heard of a language which tried to 
 include the
 return type in overload resolution. It sounds like a huge 
 complication to me.

 - Jonathan M Davis

I can envision simple ways for a programmer to supply hints to the compiler for easy resolution based on return type. For example, when calling an overloaded function without assignment to anything: int f() { ... } void f() { ... } f(); // should choose void return (void)f(); // calls void return (int)f(); // calls int return In C++ there are conversion operators, which are not exactly the same as function overloading, but the correct function is selected based on the type on the left hand side. Example class A { operator bool(){ return _b; } operator int(){ return _i; } int _i; bool _b; } A a; bool b = a; // executes bool() int i = a; // executes int() Is there anything like C++ conversion operators in D? I have used conversion ops in C++ and may want to use a similar feature in D if available. --rt
Nov 13 2012
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
On Wednesday, 14 November 2012 at 06:52:57 UTC, Rob T wrote:
 On Wednesday, 14 November 2012 at 02:01:56 UTC, Jonathan M 
 Davis wrote:
 Is there anything like C++ conversion operators in D? I have 
 used conversion ops in C++ and may want to use a similar 
 feature in D if available.
 --rt

it would be a very useful feature to allow overload on void and 1 other type... as sometimes the return is very expensive to calculate... I have seen this trick used by compiler build-in functions. struct A { int i; string s; alias i this; alias s this; } but... 2 alias this are not currently allowed.
Nov 13 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 07:26:44 UTC, Tove wrote:
 it would be a very useful feature to allow overload on void and 
 1 other type... as sometimes the return is very expensive to 
 calculate... I have seen this trick used by compiler build-in 
 functions.

 struct A
 {
   int i;
   string s;

   alias i this;
   alias s this;
 }

 but... 2 alias this are not currently allowed.

Was the single conversion limitation specified by design, or do we have room to expand it to allow for multiple conversions? In C++ I used multiple conversions for a variant class and it worked like a charm. The alternative was to manually specify a named function based on the type to return, which is not as fun to work with. --rt
Nov 14 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 08:25:30 UTC, Rob T wrote:
 Was the single conversion limitation specified by design, or do 
 we have room to expand it to allow for multiple conversions?

http://d.puremagic.com/issues/show_bug.cgi?id=6083 I guess it will be expanded to allow multiple conversions. --rt
Nov 14 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d04016ab7be048a04ce70d62c
Content-Type: text/plain; charset=UTF-8

Actually the (x) => y style delegates compute their return type exactly by
looking at the left-hand side. This exact thing is already being done. If
the ambiguity cannot be resolved, the return type is explicitly set OR the
result is casted to a type.
Having normal functions behave this way doesn't add anything new. This
already exists.


On Wed, Nov 14, 2012 at 12:30 PM, Rob T <rob ucora.com> wrote:

 On Wednesday, 14 November 2012 at 08:25:30 UTC, Rob T wrote:

 Was the single conversion limitation specified by design, or do we have
 room to expand it to allow for multiple conversions?

I guess it will be expanded to allow multiple conversions. --rt

-- Bye, Gor Gyolchanyan. --f46d04016ab7be048a04ce70d62c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually the (x) =3D&gt; y style delegates compute their return type exactl= y by looking at the left-hand side. This exact thing is already being done.= If the ambiguity cannot be resolved, the return type is explicitly set OR = the result is casted to a type.<div> Having normal functions behave this way doesn&#39;t add anything new. This = already exists.</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">On Wed, Nov 14, 2012 at 12:30 PM, Rob T <span dir=3D"ltr">&lt;<a hr= ef=3D"mailto:rob ucora.com" target=3D"_blank">rob ucora.com</a>&gt;</span> = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Wednesday, 14 November = 2012 at 08:25:30 UTC, Rob T wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Was the single conversion limitation specified by design, or do we have roo= m to expand it to allow for multiple conversions?<br> <br> </blockquote> <br> </div><a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id=3D6083" targ= et=3D"_blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id=3D6083</= a><br> <br> I guess it will be expanded to allow multiple conversions.<span class=3D"HO= EnZb"><font color=3D"#888888"><br> <br> --rt<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan.<br> </div> --f46d04016ab7be048a04ce70d62c--
Nov 14 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 14, 2012 13:05:41 Gor Gyolchanyan wrote:
 Actually the (x) => y style delegates compute their return type exactly by
 looking at the left-hand side. This exact thing is already being done. If
 the ambiguity cannot be resolved, the return type is explicitly set OR the
 result is casted to a type.
 Having normal functions behave this way doesn't add anything new. This
 already exists.

I think that you're wrong about that. (x) => y lambdas are no different from any other delegate literals save for their syntax. The type of x is dependent on what's being passed to it, and the type of y depends on x and what the function does. It shouldn't have any need whatsoever to look at the expression that the lambda is being used in, just what's passed to it. - Jonathan M Davis
Nov 14 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2012 1:34 PM, Rob T wrote:
 I'm wondering why overloading has been implemented to only match on the
argument
 list rather than the full signature which includes the return type? I know I
 would use it if it was available.

 I'm not requesting this to be a feature of D, I'm only asking why it is not
 being done.

Because types are resolved bottom-up, and if the return type were part of the overloading, there would be no sensible rule to determine the types.
Nov 14 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2012 06:30 PM, Rob T wrote:
 On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright wrote:
 I'm not requesting this to be a feature of D, I'm only asking why it
 is not
 being done.

Because types are resolved bottom-up, and if the return type were part of the overloading, there would be no sensible rule to determine the types.

But doesn't the compiler already have to perform overload-like decision making on return types in the "alias this" case, esp once multiple conversions are allowed? class A{ int i; bool b; alias i this; alias b this; } main() { auto a = new A; int i = a; bool b = a; } --rt

alias this is not the best example, but the necessary logic is basically already in the compiler. Lambda parameter type deduction based on the expected type is a similar task. It is not being done because it is not being done. Full type inference would be even more fun.
Nov 14 2012
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 14.11.2012 20:07, schrieb Timon Gehr:
 On 11/14/2012 06:30 PM, Rob T wrote:
 On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright wrote:
 I'm not requesting this to be a feature of D, I'm only asking why it
 is not
 being done.

Because types are resolved bottom-up, and if the return type were part of the overloading, there would be no sensible rule to determine the types.

But doesn't the compiler already have to perform overload-like decision making on return types in the "alias this" case, esp once multiple conversions are allowed? class A{ int i; bool b; alias i this; alias b this; } main() { auto a = new A; int i = a; bool b = a; } --rt

alias this is not the best example, but the necessary logic is basically already in the compiler. Lambda parameter type deduction based on the expected type is a similar task. It is not being done because it is not being done. Full type inference would be even more fun.

In the lambda case it's return type deduction and not overload resolution. Those are actually two very different things.
Nov 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/15/2012 07:09 PM, Sönke Ludwig wrote:
 Am 14.11.2012 20:07, schrieb Timon Gehr:
 On 11/14/2012 06:30 PM, Rob T wrote:
 On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright wrote:
 I'm not requesting this to be a feature of D, I'm only asking why it
 is not
 being done.

Because types are resolved bottom-up, and if the return type were part of the overloading, there would be no sensible rule to determine the types.

But doesn't the compiler already have to perform overload-like decision making on return types in the "alias this" case, esp once multiple conversions are allowed? class A{ int i; bool b; alias i this; alias b this; } main() { auto a = new A; int i = a; bool b = a; } --rt

alias this is not the best example, but the necessary logic is basically already in the compiler. Lambda parameter type deduction based on the expected type is a similar task. It is not being done because it is not being done. Full type inference would be even more fun.

In the lambda case it's return type deduction and not overload resolution. Those are actually two very different things.

Yes, lambda _return_ type deduction is less related, but I have never claimed otherwise. Another case that shows how a compiler must be able to take into account the left hand side of an assignment in order to type check the right hand side: int foo(int); double foo(int); void main(){ double function(int) fun = &foo; }
Nov 15 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 15.11.2012 22:05, schrieb Timon Gehr:
 On 11/15/2012 07:09 PM, Sönke Ludwig wrote:
 Am 14.11.2012 20:07, schrieb Timon Gehr:
 On 11/14/2012 06:30 PM, Rob T wrote:
 On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright wrote:
 I'm not requesting this to be a feature of D, I'm only asking why it
 is not
 being done.

Because types are resolved bottom-up, and if the return type were part of the overloading, there would be no sensible rule to determine the types.

But doesn't the compiler already have to perform overload-like decision making on return types in the "alias this" case, esp once multiple conversions are allowed? class A{ int i; bool b; alias i this; alias b this; } main() { auto a = new A; int i = a; bool b = a; } --rt

alias this is not the best example, but the necessary logic is basically already in the compiler. Lambda parameter type deduction based on the expected type is a similar task. It is not being done because it is not being done. Full type inference would be even more fun.

In the lambda case it's return type deduction and not overload resolution. Those are actually two very different things.

Yes, lambda _return_ type deduction is less related, but I have never claimed otherwise. Another case that shows how a compiler must be able to take into account the left hand side of an assignment in order to type check the right hand side: int foo(int); double foo(int); void main(){ double function(int) fun = &foo; }

The point I was trying to make is that taking the LHS into account is one thing (be it return type or parameter type deduction). But selecting the right overload in presence of implicit type conversions is much more than that and brings a lot of problems. In particular I suspect that a solution could either be to flag every possible ambiguity as an error and thus possibly make resulting APIs badly usable, or to define resolution rules to at least handle some ambiguities but in turn make it difficult and non-obvious for the programmer what happens. There can also be hidden ambiguities with number literals or custom operator overloads, things that are solvable but all add up. But then again I don't really have concrete use cases that I can think of, so maybe in real cases it would not matter anyway and going with the always-error-out route would be fine.
Nov 15 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 09:16:13 UTC, Walter Bright 
wrote:
 I'm not requesting this to be a feature of D, I'm only asking 
 why it is not
 being done.

Because types are resolved bottom-up, and if the return type were part of the overloading, there would be no sensible rule to determine the types.

But doesn't the compiler already have to perform overload-like decision making on return types in the "alias this" case, esp once multiple conversions are allowed? class A{ int i; bool b; alias i this; alias b this; } main() { auto a = new A; int i = a; bool b = a; } --rt
Nov 14 2012
prev sibling next sibling parent reply "foobar" <foo bar.com> writes:
On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
 I'm wondering why overloading has been implemented to only 
 match on the argument list rather than the full signature which 
 includes the return type? I know I would use it if it was 
 available.

 I'm not requesting this to be a feature of D, I'm only asking 
 why it is not being done.

 --rt

This is hardly a new idea. It was implemented in a few languages of the 70's and it proved to be adding complexity and generally not worth the trouble. No language nowadays bothers with this based on those past lessons.
Nov 14 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2012 06:43 PM, foobar wrote:
 On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
 I'm wondering why overloading has been implemented to only match on
 the argument list rather than the full signature which includes the
 return type? I know I would use it if it was available.

 I'm not requesting this to be a feature of D, I'm only asking why it
 is not being done.

 --rt

This is hardly a new idea. It was implemented in a few languages of the 70's and it proved to be adding complexity and generally not worth the trouble.

I guess they just were not doing it right then.
 No language nowadays bothers with this based on those past lessons.

Haskell.
 fromInteger 2 :: Float

Nov 14 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 14 November 2012 at 06:52:57 UTC, Rob T wrote:
 In C++ there are conversion operators, which are not exactly 
 the same as function overloading, but the correct function is 
 selected based on the type on the left hand side.

 Example

 class A
 {
    operator bool(){ return _b; }
    operator int(){ return _i; }
    int _i; bool _b;
 }

 A a;
 bool b = a; // executes bool()
 int i = a; // executes int()

 Is there anything like C++ conversion operators in D? I have 
 used conversion ops in C++ and may want to use a similar 
 feature in D if available.


 --rt

Not really, that has *nothing* to do with "the correct function is selected based on the type on the left hand side", but just C++ trying to match the signature of the constructor it is trying to call. As a matter of fact, as a rule of thumb, there is no "left hand side" for the compiler. Just functions and arguments. It is absolutely no different from: //---- void foob(bool); void fooi(int); A a; foob(a); //Executes bool() fooi(a); //Executes int() //----
Nov 14 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 14 November 2012 at 06:52:57 UTC, Rob T wrote:
 In C++ there are conversion operators, which are not exactly 
 the same as function overloading, but the correct function is 
 selected based on the type on the left hand side.

 Example

 class A
 {
    operator bool(){ return _b; }
    operator int(){ return _i; }
    int _i; bool _b;
 }

 A a;
 bool b = a; // executes bool()
 int i = a; // executes int()

 Is there anything like C++ conversion operators in D? I have 
 used conversion ops in C++ and may want to use a similar 
 feature in D if available.


 --rt

Not really, that has *nothing* to do with "the correct function is selected based on the type on the left hand side", but just C++ trying to match the signature of the constructor it is trying to call. As a matter of fact, as a rule of thumb, there is no "left hand side" for the compiler. Just functions and arguments. It is absolutely no different from: //---- void foob(bool); void fooi(int); A a; foob(a); //Executes bool() fooi(a); //Executes int() //----
Nov 14 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Wednesday, 14 November 2012 at 19:12:59 UTC, Timon Gehr wrote:
 On 11/14/2012 06:43 PM, foobar wrote:
 On Tuesday, 13 November 2012 at 21:34:28 UTC, Rob T wrote:
 I'm wondering why overloading has been implemented to only 
 match on
 the argument list rather than the full signature which 
 includes the
 return type? I know I would use it if it was available.

 I'm not requesting this to be a feature of D, I'm only asking 
 why it
 is not being done.

 --rt

This is hardly a new idea. It was implemented in a few languages of the 70's and it proved to be adding complexity and generally not worth the trouble.

I guess they just were not doing it right then.
 No language nowadays bothers with this based on those past 
 lessons.

Haskell.
 fromInteger 2 :: Float


I thought that Haskell doesn't have function overloading (which simplifies this greatly)... Anyway, I mostly meant "standard" imperative/OO languages. Sorry for the confusion.
Nov 15 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
I've been wondering for a couple of years about why overloading 
stops at the argument sig in almost all languages, but so far I 
have not seen a good reason why this must be so.

 From what I've read so far, the reason why full overloading is 
not being done, is because it is not being done. Other than that, 
I don't have an answer as to why it is not being done because 
clearly it can be done, and the compiler certainly has the means 
to do it already, otherwise it could not err when you assign a 
function return type to the wrong type on the LHS, ie, it most 
certainly is able to determine what the full signature is at some 
point.

So does anyone really know why it is not being done? The "it's 
too complicated" argument seems weak to me since the compiler 
already has to check for both matching argument sig as well as 
the return type, and it already does overloading on the argument 
sig. I figure "it's too complicated" only because the compiler 
was initially designed without taking full signature overloading 
into account from the very start, otherwise it would be not much 
more complicated than the regular overloading that we have now.

The argument that the compiler will get too confused seems a bit 
weak as well, since the compiler can already get confused with 
argument sig overloading, and there are certainly methods of 
working this out, otherwise function overloading would not work 
as it is now. At the end of the day, if the compiler cannot 
figure it out, then it errs, just as it does now when it cannot 
figure it out. There's already an incalculable number of ways a 
programmer can mess up a valid compile, so adding one more 
possible way to the already massive pile cannot be used as a 
reason why it should not be done.

I could argue that overloading only on function sig is too 
complicated and not worth it, but we have it, and it is useful to 
at least some or most people, so why did we stop at the argument 
sig and not go all the way? Is there a theoretical reason why we 
should stop, are their use cases that have shown that it fails to 
help the programmer or makes programming more difficult?

--rt
Nov 15 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 15 November 2012 at 17:18:04 UTC, Rob T wrote:
 I've been wondering for a couple of years about why overloading 
 stops at the argument sig ...

 [SNIP]

 --rt

I'd say because overall, you gain *very* little out of it, and it costs you much more complex compiler rules. Most of all though, I'd say it is a bad idea in and out of itself: If you overload on the return type, you open the floodgates to call ambiguity. I mean, are there even any real use-cases for overload on return type?
Nov 15 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
monarch_dodra:

 I mean, are there even any real use-cases for overload on 
 return type?

In Haskell many functions are "overloaded" on the return type (like the fromString function), and it's nice. But Haskell is able to do it because it has a global type inferencer. Bye, bearophile
Nov 15 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Thursday, 15 November 2012 at 17:33:24 UTC, monarch_dodra 
wrote:
 I'd say because overall, you gain *very* little out of it, and 
 it costs you much more complex compiler rules.

But how little, and for how much extra cost? Overloading already has a cost to it, and it's really difficult for me to understand why adding return type to the mix has to be be many times more costly. I will confess that I'm not a compiler designer, but I can still try to imagine what would be needed. Already the compiler MUST ensure that the return type is valid, so we're essentially already there from what I can see.
 Most of all though, I'd say it is a bad idea in and out of 
 itself: If you overload on the return type, you open the 
 floodgates to call ambiguity.

Sure, but not much more so that we have already with the current overloading system, and the compiler can certainly prevent an invalid compile from happening when there is even a hint of ambiguity, as it does already with current overloading. Besides I would expect such a feature to be used by advanced programmers who know what they are doing because overloading in general is an advanced feature and it is certainly not for the easily confused.
 I mean, are there even any real use-cases for overload on 
 return type?

Yes, I've wanted this for a few years, and I have used a similar feature successfully through C++ class operator conversions. I brought up the example of operator conversion for classes in C++. I know some of you have said it's not the same thing, but IMO it is the same thing. int x = a; string y = a; Does "a" represent a class or a function? Why should it matter? class A { int i; string s; alias i this; alias s this; // ouch D does not allow it! ... } UFCS int convert( A a ) { return a.i; } string convert( A a ) { return a.s; } int i = a.convert; string s = a.convert; A real-world use case example is to implement Variant types more naturally, where you could do the above and have it convert to int or string (and other types) on demand depending on the validity of data type. Obviously it will run-time error when the type cannot be converted, or perform whatever logic the programmer desires. --rt
Nov 15 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 15, 2012 17:18:43 foobar wrote:
 I thought that Haskell doesn't have function overloading (which
 simplifies this greatly)... Anyway, I mostly meant "standard"
 imperative/OO languages. Sorry for the confusion.

It has pattern matching (which typically results in several of the same function with slightly different arguments, but the overall types are still the same). I'm unaware of it having full-on function overloading. But I don't think that I've ever tried it. - Jonathan M Davis
Nov 15 2012
prev sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 16 November 2012 at 01:02:59 UTC, Jonathan M Davis 
wrote:
 On Thursday, November 15, 2012 17:18:43 foobar wrote:
 I thought that Haskell doesn't have function overloading (which
 simplifies this greatly)... Anyway, I mostly meant "standard"
 imperative/OO languages. Sorry for the confusion.

It has pattern matching (which typically results in several of the same function with slightly different arguments, but the overall types are still the same). I'm unaware of it having full-on function overloading. But I don't think that I've ever tried it. - Jonathan M Davis

This article describes return type overloading in Haskell by way of a clear example. It concludes demonstrating a real-world implementation of the concept. http://matthewmanela.com/blog/return-type-overloading-in-haskell/ I'm not well versed in Haskell (first look ever), so I'm not sure, but it does seem to look like true return type overloading. I also read an article that described Perl's overloading on return type, but this is less like the overloading we've been talking about, and more like a function being able to inspect the call context to decide what type should be returned. --rt
Nov 15 2012