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

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?

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

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

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

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.

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

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

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

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?
>>
>>
> http://d.puremagic.com/issues/**show_bug.cgi?id=6083<http://d.puremagic.com/issues/show_bug.cgi?id=6083>
>
> I guess it will be expanded to allow multiple conversions.
>
> --rt
>



-- 
Bye,
Gor Gyolchanyan.