DIP1000: The return of 'Extend Return Scope Semantics'

[kinke]

On Tuesday, 25 May 2021 at 11:24:59 UTC, Dennis wrote:
> But there's currently now way of making `target` the return 
> scope destination when it's not the first parameter. So unless 
> we want to leave `move` `@system` or create a `move2` function 
> with parameters reversed, we're back at the drawing board for 
> "Extend Return Scope Parameters". Two earlier proposals were:
>
> ```D
> // Mike Franklin's proposal:
> void move(T)(return(target) T source, ref scope T target)
>
> // Steven Schveighoffer's proposal:
> void move(T)(return T source, @__sink ref scope T target)
> ```
>
> What do you think?

Good overview, thanks for the post. If we don't really need a 
generic solution for that, i.e., can expect new code to use the 
first param and `move` to be the only problematic existing code, 
a possibility would be to make `move` and `forward` compiler 
intrinsics. The compiler can handle those much more efficiently 
than a non-trivial library solution with according template bloat.