View mode: basic / threaded / horizontal-split · Log in · Help
November 13, 2012
function overload on full signature?
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
November 13, 2012
Re: function overload on full signature?
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?
November 13, 2012
Re: function overload on full signature?
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
November 14, 2012
Re: function overload on full signature?
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
November 14, 2012
Re: function overload on full signature?
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
November 14, 2012
Re: function overload on full signature?
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.
November 14, 2012
Re: function overload on full signature?
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
November 14, 2012
Re: function overload on full signature?
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
November 14, 2012
Re: function overload on full signature?
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
November 14, 2012
Re: function overload on full signature?
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.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home