On Wednesday, 14 July 2021 at 20:55:32 UTC, wjoe wrote:
On Wednesday, 14 July 2021 at 16:13:35 UTC, Tejas wrote:
[...]
Congratulations:) Unfortunately I haven't got anything I could
return by ref so I can't take advantage of a low hanging fruit.
In my book overloading operators is no fun - at all - and
always a last resort because it requires so much time and
testing and causes so many headaches.
Workarounds exist like ```i[n] += 1``` or direct call via
```i.opIndexUnary!"++"(n)``` or simply ```++i[n]```.
But that's beside the point. There's nothing in the spec that
says something about something needs to be returned by ref.
Rewriting manually compiles and works as intended. So clearly
something else is going on which makes the compiler select
```opIndex``` over ```opIndexUnary``` rewriting it post to pre.
In my particular case the compiler can rule out ```opIndex```
so why does it abort instead of trying ```opIndexUnary``` ? Or
was it trying and it didn't work ? If that's the case I'd like
to know the reason why it discarded ```opIndexUnary```.
Anyways all the answers so far are much appreciated!
I'm so sorry all this was basically useless for you.
I can't spend more time on this, so as a last resort I leave you
this:
https://dlang.org/phobos/std_bitmanip.html
This is the official bit manipulation standard library, maybe it
will help you in some way; the ```bitfield``` struct looked
mighty familiar to your ```part_int``` struct, but maybe that's
my cognitive bias, you should verify it.
Best of luck!
