DIP1000: The return of 'Extend Return Scope Semantics'

[Atila Neves]

On Tuesday, 25 May 2021 at 22:19:23 UTC, tsbockman wrote:
> On Tuesday, 25 May 2021 at 11:46:12 UTC, kinke wrote:
>> 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,
>
> This sounds like a really annoying and arbitrary limitation.

It's not arbritrary at all - the purpose is to avoid this:

https://carols10cents.github.io/book/ch10-03-lifetime-syntax.html#lifetime-annotations-in-function-signatures

Reasonable people of course can disagree on whether or not 
avoiding that is a good idea.