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

[Paul Backus]

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`.