Const ref and rvalues again...

[Rob T]

On Wednesday, 7 November 2012 at 14:07:31 UTC, martin wrote:

> T g() {
>     T temp;
>     temp.createResource();
>     return temp; // D already moves temp!
>                  // 'Named Return Value Optimization'
> }

OK, it seems to be working as you describe.

The main question I have is if I can rely on this behaviour as a 
feature provided by the languge specification vs an opportunistic 
compiler optimization that may or may not happen depending on the 
implementation?

The general problem I'm having with with D, is I need a gaurantee 
that certain behaviors will always be performed when moves/copies 
are done, but it's just not clear if this is the case or not. 
There seems to be a lack of a concise language specification, or 
is there one defined somewhere?

> You could implement a copy constructor 'this(this)' in your 
> struct T and see when it is invoked to check when an instance 
> is actually copied. I'd expect that invoking 'f(g());' with 
> above implementation doesn't copy anything.

I am doing that, but I cannpt seem to hook into the part where a 
move does an "init" on the struct or class. I sort-of can see it 
though, if I set a member value to a known state before the move, 
then display it to console or log after the move during 
destruction. If it was init'ed then I'll see the default value, 
and this seems to be happening as described.

Anyway, what I was hoping for with "auto ref" was for the 
compiler to selectively decide if the ref part should be used or 
not depending on the situation, rather than me manually writing 
two functions to do the exact same thing. What's discussed in 
here about auto ref is something else, although I agree it is 
definitely needed.

--rt