DIP1000: The return of 'Extend Return Scope Semantics'

[Joseph Rushton Wakeling]

On Wednesday, 26 May 2021 at 12:36:42 UTC, Atila Neves wrote:
> On Tuesday, 25 May 2021 at 22:19:23 UTC, tsbockman wrote:
>> 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.

I understand that motivation, but at the same time, it's not 
necessarily good to reduce flexibility for the programmer.  I 
think I would rather have to clearly annotate my target ref/out 
parameters every time, than rely on a "magic" rule like "the 
first parameter is the targeted one".

Of course, that doesn't mean that I want to have Rust-style 
lifetime annotation if we can have something simpler and easier!  
But it would certainly be very nice to have the full scope of 
possibilities that Rust allows.  It strikes me that what D should 
aim for is notation that is clear and unambiguous in intent, but 
which scales nicely with the complexity of what the programmer 
wants to achieve (so e.g. if you want to ensure a struct instance 
outlives a pointer/reference that it wraps, you might have to do 
more annotation, but if you want to make sure that in input 
parameter outlives a returned parameter, that's simple and easy).