Feedback Thread: DIP 1040--Copying, Moving, and Forwarding--Community Review Round 1

[Walter Bright]

On 3/5/2021 11:15 AM, Paul Backus wrote:
> On Friday, 5 March 2021 at 12:20:36 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review of DIP 
>> 1040, "Copying, Moving, and Forwarding".
> 
> In the section on "Last Use":
> 
>> Module level functions that contain nested functions or lambda functions that 
>> access an outer local variable will not be subject to last use dataflow 
>> analysis. The reason is that a pointer to the nested function or lambda could 
>> be escaped from the containing function
> 
> This rule has the potential to cause "spooky action at a distance," where a 
> change to one part of a function silently causes the meaning of 
> seemingly-unrelated code in the same function to change. For example:
> 
>      struct EMO { /* ... */ }
> 
>      version (Before)
>      void example()
>      {
>          int a;
>          EMO b;
>          fun(a);
>          gun(b); // last use of b -> move
>      }
> 
>      version (After)
>      void example()
>      {
>          int a;
>          EMO b;
>          void helper() { fun(a); } // DFA disabled here
>          helper();
>          gun(b); // no DFA -> copy
>      }
> 
> Ideally, only variables that are actually accessed from nested functions would 
> have their last-use analysis disabled. In the example above, that would include 
> `a`, which is accessed in `helper`, but not `b`.

It is possible to do the DFA through nested functions. I plan on doing that with 
@live functions.

What the DIP should make clear, however, is that changing copies to moves should 
be regarded as implementation dependent, i.e. it is a mistake if the user 
attempts to rely on a particular sequence of moves and copies. Much like relying 
on this for NRVO is a mistake. NRVO has always been an optional optimization, 
and if it happens or not is difficult to determine just by looking at the code. 
In practice, the only problem that has cropped up has been pressure to find more 
cases where NRVO can be applied, so I think we're good with labeling the 
copy=>move semantics as an implementation-dependent optimization.