DIP1000: 'return scope' ambiguity and why you can't make opIndex work

[Dennis]

On Friday, 18 June 2021 at 17:04:02 UTC, ag0aep6g wrote:
> Geez, this isn't easy.

I know right? When I started to get the hang of it I was like "I 
should write a tutorial about this" followed closely by "how am I 
going to explain this in one go to someone who hasn't spelunked 
dmd/escape.d and looked at the relevant spec a dozen times?"

For this post I hoped to get across the idea that dmd has 
concepts of 'escaping by reference' for `ref int` and 'escaping 
by value' for `int*`, and that it currently sometimes goes wrong 
when you mix them. But there is so much more to cover:

- constructors act like they return `this` by `ref`, but still 
have `return scope` semantics
- `out` acts like `ref`
- `in` acts like...  I don't know. With -preview=in it's 
implementation defined whether it's `ref scope` or just `scope`, 
so is it also implementation defined what `return` applies to 
then?
- `auto ref`... Don't know how that works internally.
- `ref` in foreach is actually *not* inerhently scope like in 
parameters, and [it has its own 
hole](https://issues.dlang.org/show_bug.cgi?id=22040).
- when `scope` is inferred, could it change the meaning of 
`return` to apply to the value instead of the `ref`?
- ... who knows what I missed

Learning a complex system could be rewarding if afterwards you 
can write expressive code with lifetime tracking, but in the case 
of dip1000, after all your learning efforts you still can't write 
a routine that splits a `scope string` into a `scope(string)[]` 
because dip1000 simply can't express that.