DIP 1016 and const ref parameters

[XavierAP]

Hmmm I know about move semantics, and C++11 etc. I just don't 
know how related all that is to my original question. :)

On Wednesday, 19 June 2019 at 19:25:59 UTC, Jonathan M Davis 
wrote:
> though if I understand correctly with RVO, it may just place 
> the return value outside of the function in the first place to 
> avoid needing to move.

Indeed, unrelated:
https://dlang.org/glossary.html#nrvo

> func(foo(), bar(42), baz("hello"));
>
> assuming that none of these functions return by ref, func is 
> taking temporaries from several functions, and the spec 
> actually guarantees that they will not be copied.

Where does the spec say this?? (This case is actually my 
question.)

However, please understand that naive moving is not an answer for 
me. Moving is still work! It would still be more efficient if 
foo's parameters were references/pointers -- if D functions were 
able to bind rvalues as such.

Theoretically a compiler could optimize by realizing that if a 
value parameter is not modified by the function (and it doesn't 
fit in a register etc), it can be read at its original 
location/address in the caller's stack, i.e. by 
reference/pointer. Again, nothing to do with moving. But I really 
doubt the D compilers do this, first because C++ probably don't, 
or else all C++ programmers are wasting their fingers and screen 
real state typing const & zillions of times; and second because D 
would not be able to bind as ref in case the argument happened to 
be an rvalue.
__________

OK so I try to experiment myself:

/**********/
struct XY
{
     int x, y;
     ~this() { writeln("Destroyed!"); }
}

int sum(XY p) { return p.x + p.y; }

void main()
{
     XY p;
     p.sum;
}
/**********/

Destroyed!
Destroyed!

Note that the compiler didn't realize that p isn't needed after 
the last statement of main, as you thought.

/**********/

XY get()
{
     XY p;
     return p;
}
void main()
{
     get.sum;
}
/**********/

Destroyed!

Now with an rvalue returned from get, interesting, no copy. 
Still, I wonder what really happened. Again, moving between 
stacks would still be work. And a different optimization can 
explain this non copy, for example inlining.
__________

Again, does the spec really mention any of this moving or 
eliding? I have found nothing.