DIP1000: The return of 'Extend Return Scope Semantics'

[ZachAttack!]

On Saturday, 29 May 2021 at 11:32:50 UTC, Dennis wrote:
>> We want to express:
>> ```D
>> //                       ┌─────────>─────────┐
>> void move(T)(return T source, ref scope T target)
>> ```
>
> Here's a simple extension idea: 
> https://github.com/dlang/dmd/pull/12601
>
> Simply skip over `return` parameters when looking for the 
> 'first' parameter, since making a `return` parameter its own 
> destination has no use. It's still constraining the parameter 
> order, but may be good enough to move forward with `move`.

It might be more accurate to say, "A simple extension idea, built 
upon several other 'simple extension ideas,' such that the 
keyword which activates the feature is now completely 
counterintuitive!"

Apart from the counterintuitive meaning, the other downside, as I 
see it, would be if the `return` keyword were stretched to the 
point of exhaustion, and yet still proved insufficient. At that 
point, a more robust solution would have to be added, and the new 
solution would have to exist side-by-side with existing 
overextended uses of `return`.

Perhaps in the end, `return` alone, totally out of its element, 
will nonetheless cover all necessary use cases. But if not, for 
example, the system I proposed my prior post 
(https://forum.dlang.org/post/cdurilferuuvwgciqdtb@forum.dlang.org) could replace the above extension of `return` in a far more intuitive way. The system uses designated attributes to refer to built-in lifetime routing channels. If we use, for example, `@in1` and `@out1` for channel 1, the `move` function would look like this:
```D
//                    ┌─────────────>───────────┐
void move(T)(@in1 T source, @out1 ref scope T target)
```
Under this system, the `return` attribute can still be defined—it 
is a routing channel which automatically attaches to the first 
viable target, starting with the return reference and then 
through... whatever the sequence is....

The main point is that if `return` is stretched as far as 
possible, the day may come when it will be forced to live 
side-by-side with a replacement which covers much of the same 
territory.

It's likely a manageable problem, a small stain on future 
incarnations of the language. But worth mentioning.