DIP1000: The return of 'Extend Return Scope Semantics'

[tsbockman]

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. 
Among other things, it interferes with the API designer's ability 
to freely choose which parameter they want to serve as the 
pseudo-`this` for UFCS.

Being able to make that choice is important both for aesthetic 
reasons, but more importantly to enable "extension methods" that 
allow writing generic code that accepts both custom types, and 
built-in types which are not otherwise extensible.

Also, what about C interop? APIs written in C often contain 
functions which otherwise obey the semantics of `scope` and 
`return`, but will not respect arbitrary limitations on the order 
of parameters.