View mode: basic / threaded / horizontal-split · Log in · Help
October 21, 2012
Overload resolution (value vs reference)
How does compiler selects the proper function among overloaded
functions which differ only in the way the argument is passed (by
reference or by value)? Is there a way, to control this behavior?

Result of execution of the test code:
passed by value: 8
passed by value: 3
passed by value: Foo(10)


Test code:

import std.stdio;

struct Foo {
     int value;
}

void f(T)(T foo)
{
     writeln("passed by value: ", foo);
}

void f(T)(const ref T foo)
{
     writeln("passed by reference: ", foo);
}

void main()
{
     // 8 is a r-vlaue, so it's passed by value
     f(8);

     // i is a l-value, it's passed by value and it's ok
     int i = 3;
     f(i);

     // foo is a l-value, it's passed by value again, but if
structure will be big enough it'll be ineffective

     auto foo = Foo();
     foo.value = 10;
     f(foo);
}
October 21, 2012
Re: Overload resolution (value vs reference)
On Sun, 2012-10-21 at 19:01 +0200, m0rph wrote:
> How does compiler selects the proper function among overloaded
> functions which differ only in the way the argument is passed (by
> reference or by value)? Is there a way, to control this behavior?
> 
> Result of execution of the test code:
> passed by value: 8
> passed by value: 3
> passed by value: Foo(10)
> 
> 
> Test code:
> 
> import std.stdio;
> 
> struct Foo {
>       int value;
> }
> 
> void f(T)(T foo)
> {
>       writeln("passed by value: ", foo);
> }
> 
> void f(T)(const ref T foo)
> {
>       writeln("passed by reference: ", foo);
> }
> 
> void main()
> {
>       // 8 is a r-vlaue, so it's passed by value
>       f(8);
> 
>       // i is a l-value, it's passed by value and it's ok
>       int i = 3;
>       f(i);
> 
>       // foo is a l-value, it's passed by value again, but if
> structure will be big enough it'll be ineffective
> 
>       auto foo = Foo();
>       foo.value = 10;
>       f(foo);
> }
> 

http://dlang.org/function.html#function-overloading

The big thing to remember here is that constness matters more than
refness when overloads are chosen, so if you want refness to matter when
choosing an overload, then the constness of the overloads must match,
and if there's ever a question between const and non-const, it's the
constness of the argument being passed in which wins (e.g. if you have
ref T and const ref T, then which one gets called depends on whether the
argument is const or not).

As your code stands, if it were

void f(T)(T foo)
{
   f(foo);
}

void f(T)(const ref T foo)
{
   //...
}

you would get an infinite loop when passing an rvalue to f, whereas

void f(T)(const T foo)
{
   f(foo);
}

void f(T)(const ref T foo)
{
   //...
}

would not.

- Jonathan M Davis
October 22, 2012
Re: Overload resolution (value vs reference)
Thanks for explanation!
October 22, 2012
Re: Overload resolution (value vs reference)
On Sunday, 21 October 2012 at 22:47:00 UTC, Jonathan M Davis 
wrote:

> http://dlang.org/function.html#function-overloading
>
> The big thing to remember here is that constness matters more 
> than refness when overloads are chosen, so if you want refness 
> to matter when choosing an overload, then the constness of the 
> overloads must match, and if there's ever a question between 
> const and non-const, it's the constness of the argument being 
> passed in which wins (e.g. if you have ref T and const ref T, 
> then which one gets called depends on whether the argument is 
> const or not).

 There any word on if this was going to change? I'm meaning 
towards structs/classes with const preference vs non-const 
preferences. I recall a while back while trying to make copy/move 
functions and I had to completely duplicate the functions so it 
would use the right versions.
October 22, 2012
Re: Overload resolution (value vs reference)
On Monday, October 22, 2012 22:54:44 Era Scarecrow wrote:
> On Sunday, 21 October 2012 at 22:47:00 UTC, Jonathan M Davis
> 
> wrote:
> > http://dlang.org/function.html#function-overloading
> > 
> > The big thing to remember here is that constness matters more
> > than refness when overloads are chosen, so if you want refness
> > to matter when choosing an overload, then the constness of the
> > overloads must match, and if there's ever a question between
> > const and non-const, it's the constness of the argument being
> > passed in which wins (e.g. if you have ref T and const ref T,
> > then which one gets called depends on whether the argument is
> > const or not).
> 
> There any word on if this was going to change? I'm meaning
> towards structs/classes with const preference vs non-const
> preferences. I recall a while back while trying to make copy/move
> functions and I had to completely duplicate the functions so it
> would use the right versions.

AFAIK, there are no plans to change it. I don't think that it's even been 
suggested.

For the most part though, you can just have the non-ref version call the ref 
version as long as there's a ref version with the same constness, so even if 
you have to duplicate the function, you don't have to duplicate its body. You 
might be stuck with some duplication between the const and non-const overloads 
though if you have all 4 of them.

- Jonathan M Davis
October 23, 2012
Re: Overload resolution (value vs reference)
On Monday, 22 October 2012 at 21:58:04 UTC, Jonathan M Davis 
wrote:
> AFAIK, there are no plans to change it. I don't think that it's 
> even been suggested.

 I thought I suggested it back for a different order of 
preferences. Basically boils down to accepting the const ones 
over the non-const whenever applicable and possible. Quite 
annoying that it was accepting non-const copy over const ref for 
the purposes I was going for.

> For the most part though, you can just have the non-ref version 
> call the ref version as long as there's a ref version with the 
> same constness, so even if you have to duplicate the function, 
> you don't have to duplicate its body. You might be stuck with 
> some duplication between the const and non-const overloads 
> though if you have all 4 of them.

 Yeah I know... I guess best practice is to offer all const or 
non-const of particular function names/uses, but that doesn't 
always want to work. Let's see how did that go...

 struct S {
   ref S opAssign(S s);           //move. TDPL pg. 257-259
   ref S opAssign(const ref S s); //copy (almost postblitz)

/* as of current, only the 'move' is always used unless the 
struct is actually const. inout isn't applicable I think. I'm 
promising not to change the input on the copy, and the move can't 
be const (if there's any addressing to transfer). I consider the 
reference the important distinction, yet the non-const is always 
called/preferred */

   ref S opAssign(const S s); //duplicate(s) of above in reverse
   ref S opAssign(ref S s);   //best match works better now
 }
Top | Discussion index | About this forum | D home