opIndexMember

[Dennis]

On Sunday, 27 December 2020 at 17:01:47 UTC, claptrap wrote:
> It wont work with ref returns, and performance in release 
> builds.

What if you used pointers instead? Maybe it can be optimized when 
you make opIndex return a structure like this:

> struct VecArrayIndex {
>     VecArray* vecArray;
>     size_t index;
>     ref float x() {return vecArray.x[index];}
>     ref float y() {return vecArray.y[index];}
> }

I'm not trying to annoy you with awkward workarounds, I see what 
you're going for. I just really don't want operator overloading 
to become more complex than it already is. It's already confusing 
having opIndex, opSlice, opSliceUnary, opAssign, opIndexAssign, 
opIndexOpAssign, opIndexUnary etc. And then there's still some 
cases missing that the compiler uses for internal types that 
can't be expressed in library types:

- multiple array concatenation without multiple re-allocations, 
e.g. `a ~ b ~ c` gets rewritten to a single call.
- for associative arrays, opIndex followed by opIndexAssign, e.g. 
for an `int[string][string]` doing `aa["newKey"]["anotherNewKey"] 
= 1` does not give a range violation for `aa["newKey"]`.

So there's good rationale for adding solutions to that so library 
solutions can replace compiler magic.

Now you propose, opIndexMember, but that's just the beginning of 
even more possible combinations: next you'll need 
opIndexMemberAssign, opIndexMemberOpAssign, and who knows what.

So that's why I want to fix / improve operator overloading 
without adding any more cases if it can be helped.