Using in as a parameter qualifier

[Ali Çehreli]

On 05/31/2013 04:41 PM, Shriramana Sharma wrote:

 > On Fri, May 31, 2013 at 8:55 PM, Jonathan M Davis 
<jmdavisProg at gmx.com> wrote:
 >> In D, const ref does not accept rvalues (unlike C++'s const &).
 >
 > So what is the syntax that accepts rvalues and yet does not make a
 > copy of the input object?

I think there has been some resolution on that but it has not been 
implemented yet. I have not read all of the thread. Can others give a 
summary of the following thread please?

   http://forum.dlang.org/thread/km3k8v$80p$1@digitalmars.com

 > I mean, as Ali says OK profiling is
 > preferable to find out where exactly passing by value is more
 > efficient than passing by const ref, but I'd like to know anyway what
 > is the syntax available for this

That syntax is not available yet. Currently you can take by 'ref const' 
that does not accept rvalues, or take by value that works for both.

Of course there is also function overloading:

import std.stdio;

struct S
{
     int[100] big;
}

void foo(ref const(S) s)
{
     writeln("lvalue arg passed by ref");
}

void foo(S s)
{
     writeln("either lvalue arg has been copied or rvalue arg has been 
moved");
}

void main()
{
     auto s = S();

     foo(s);
     foo(S());
}

However, even the lvalue goes to the by-copy overload of foo:

either lvalue arg has been copied or rvalue arg has been moved
either lvalue arg has been copied or rvalue arg has been moved

  Is that by-design? The lvalue s goes to the by-ref overload only if 
the variable is const to begin with:

     auto s = const(S)();

Now the output is this:

lvalue arg passed by ref
either lvalue arg has been copied or rvalue arg has been moved

Is that how the overload resolution rules work? Have I asked this 
already? Why don't I remember? :)

Maybe the programmer should not have such large structs anyway. It is 
always an option to use a slice instead of that fixed-length array.

 > I just finished reading this link which Ali gave:
 > 
http://bartoszmilewski.com/2008/11/03/who-ordered-rvalue-references-part-3/
 > but perhaps due to my ignorance I don't get 100% what he is tryring to
 > say.

That article is about how moving objects is a fundamental operation of 
D. C++ has three popular basic operations: construction, copy, and 
assignment. C++11 brings another one: move. Move has been a fundamental 
struct operation in D for a long time now.

 > Is it really relevant for what I am asking, like avoiding a
 > copy-constructor in the input of a function which will not modify its
 > input, even if I pass by value?

No, not directly relevant but structs object are supposed to be values 
without identities. The compiler can move them around freely. Maybe that 
is a better way of looking at the problem.

For example, there is not a concept of a copy constructor. The compiler 
bit-copies and then provides a chance to make corrections. That is 
different from C++.

 > unfinished language features (scope?)

'scope' is not essential at all, but you are right: There may be other 
issues down the road.

 > I think I may stick with C++ at least for the present project and 
maybe use
 > D for future ones. Advice?

I will let you and others answer that question.

Ali