DIP1000: The return of 'Extend Return Scope Semantics'

[Paul Backus]

On Wednesday, 26 May 2021 at 13:01:24 UTC, jmh530 wrote:
> On Wednesday, 26 May 2021 at 12:36:42 UTC, Atila Neves wrote:
>> [snip]
>>
>> 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.
>
> I also couldn't help but think of Rust's lifetime annotations 
> when reading the OP's post. Rust's is more expressive though. 
> If you try to limit it, then there obviously will be cases that 
> you can't cover everything without making it more complicated. 
> I can't help but think that return should be something like 
> lifetime(return) instead. Then you can have 
> lifetime(variableA), lifetime(variableB). It's a bit more 
> confusing to have return(variableA)/return(variableB).

D's general philosophy w.r.t. memory safety so far has been to 
try and balance ease of use and comprehension with 
expressiveness. D's `scope` and `return` are less expressive than 
Rust's lifetimes, but that expressiveness may be worth giving up 
if it's easier to write correct `@safe` and DIP1000-compliant 
code than it is to write correct Rust code.

Of course, D's vision here is severely hampered in practice by 
the poor quality of its documentation (raise your hand if you can 
explain what ["return ref parameter semantics with additional 
scope parameter semantics"][1] actually means). But that's the 
idea.

[1]: 
https://dlang.org/spec/function.html#ref-return-scope-parameters