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

[Dukc]

On Saturday, 19 June 2021 at 19:40:36 UTC, Dennis wrote:
> I *think* this is sound because there is no way a `ref` 
> outlives its `scope` members, so the lifetime of the returned 
> value is simply the one of the `ref` (which is the smaller 
> one). However, I feel like there's a caveat I overlooked. Can 
> the solution really be this simple?

Well, I had to think this one really hard.

Your solution has one disadvantage:

```d
struct CustomPtr {
    private ubyte* ptr;
    //works, but suboptimal
    ubyte* opUnary(string op)() if(op=="*") return scope {return 
ptr;}
}
```

With your solution, DIP1000 will prevent the return value of 
`*customPtr` outliving `customPtr`. We would ideally want only to 
prevent `*customPtr` outliving whatever `customPtr.ptr` points 
to, which is what happens now if I understood the table right.

But I can see no flaw in changing the field "`ref` arg / `ref` 
return / `scope`" to "both".

Whether the complexity of the current semantics are worth it 
because of the issue I mentioned, I'm not sure at all. It's 
highly likely there are more corner cases lurking about. I have a 
feeling that we should go with your proposal, or continue 
brainstorming. Deriving the `scope` semantics from return value 
makes too much assumptions about the intention.