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

[Dennis]

On Saturday, 19 June 2021 at 09:43:18 UTC, ag0aep6g wrote:
> But:
>
> * That's still hard to figure out, especially with methods 
> because `ref this` is invisible.

On top of that, `scope` could be invisible behind `in`.

Here's an idea: could `return` apply to both the `ref` and value 
if there is `return scope`?

|                                 | `scope`   | no `scope` |
|---------------------------------|-----------|------------|
| `ref` return type / `ref` param | **both**  | **`ref`**  |
| value return type / `ref` param | **both**  | **`ref`**  |
| `ref` return type / value param | **value** | **value**  |
| value return type / value param | **value** | **value**  |

The table would simply become:

|             | `scope`   | no `scope` |
|-------------|-----------|------------|
| `ref` param | **both**  | **`ref`**  |
| value param | **value** | **value**  |

You could even make this work then:
```D
struct Vector {
     float[4] small; // return ref
     float[] large; // return scope
     bool isSmall;

     ref float opIndex(size_t i) return scope {
         return isSmall ? small[i] : large[i]; // dynamically 
choose
     }
}
```

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?