Is NRVO part of the spec?

[via Digitalmars-d]

On Saturday, 7 February 2015 at 16:10:48 UTC, Andrei Alexandrescu 
wrote:
> On 2/7/15 8:02 AM, Daniel Murphy wrote:
>> "Andrei Alexandrescu"  wrote in message
>> news:mb59ej$2j7s$1 at digitalmars.com...
>>
>>> > NRVO isn't required for correct semantics, as structs can 
>>> > be moved with
>>> > bitcopy.
>>>
>>> It is required for structs that disable postblit. -- Andrei
>>
>> IIRC they only require that no copies are made.  They can 
>> still be moved.
>
> Exactly - as you just said in the other post, the spec must 
> clarify when things are guaranteed to be moved and not copied.
>
> That includes:
>
> 1. URVO: returning an rvalue does not entail a copy.
>
> 2. Last return of a function local variable does not entail a 
> copy.

I think this needs to be phrased differently: Any returned value 
can be moved iff none of the destructors, scope(exit)'s and 
finallys that are run as part of the cleanup can possibly access 
the value's original location. (I assume that the move happens 
_before_ the destructors are called. This is reasonable because 
otherwise said destructors could modify the returned value "in 
flight".) This formulation also encompasses rvalues.

>
> That's actually more than NRVO because NRVO requires the same 
> local be returned from all paths. Example:
>
> T fun(bool b) {
>   if (b) { T a; return a; }
>   T b;
>   return b;
> }
>
> This should work if T is noncopyable. It may be less efficient 
> than it could though.
>
> 3. The more complicated/ambitious cases involve the last use of 
> a value. Consider:
>
> T fun() {
>   T a;
>   T b = a;
>   return b;
> }
>
> Even though the code ostensibly makes a copy, it's the last use 
> of a so that could be a move.

This is arguably different, because it doesn't involve a return.

>
> I think (3) could be used for optimization but it's too much of 
> a headache to put in the language definition. We do need to 
> have (1) and (2) covered.
>
>
> Andrei