opIndexMember

[claptrap]

On Sunday, 27 December 2020 at 23:06:47 UTC, Dennis wrote:
> 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];}
>> }

That gives identical codegen to just accessing the arrays 
directly, so codegen is as good as it can be!


> 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:

To be honest I expected a bit more enthusiasm for the idea but Im 
not going to be upset or lose any sleep over it. I already had a 
work around, just that workarounds are not solutions, they avoid 
the problem rather than solving them. So I though it would be a 
nice addition to make SOA vs AOS easier to implement and easier 
for the compiler to produce optimal code.

I hadnt thought of the consequences of it spawning other op 
overloads.