DIP1000: The return of 'Extend Return Scope Semantics'

[Steven Schveighoffer]

On 5/25/21 7:24 AM, 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?

Re-reading that thread, there is more to the proposal than just the 
attribute -- the fact that the @__sink attribute would be inferred on 
templates. So no attribute would be necessary on `move`, even if the 
attribute is added for non-templates/non-auto functions (ditto for 
Mike's proposal).

That being said, Mike's proposal is obviously more flexible, as it 
allows multiple return parameters that link to multiple input 
parameters. But the cases in which those are present are super-rare.

I also don't like having a keyword (return) match with an attribute 
(@__something), as they seem unrelated, and the only reason an attribute 
would be to avoid adding a keyword. But that's a bit of bikeshedding (we 
could actually add a __keyword anyway since double-underscores are 
reserved).

-Steve