[tauoverpi]

I initially ended up with a similar-ish chunk iterator [1][2] after a few iterations however even with that I found that the optimizer wouldn't remove the bookeeping required for maintainining the iterator state itself. This is where things shifted towards using inversion of control and inlining [3] to get better results [4][5].

From my testing (I should have kept the results) the optimizer isn't always smart enough and requires a bit of hand-holding to get there and as long as you cannot express `noalias` on slices (maybe a missing zig proposal? I don't know how to propose this one) independent of function parameters it might never auto-vectorize your code as it cannot be sure that another mutation isn't taking place (if you call a function) even if you have const slices. The switch from generating an `@call` tuple to passing a struct of slices ended up with losing auto-vectorization for AECS as an example as it isn't possible to specify `noalias`.

The stronger argument for only having the chunk API is that you gain the ability to treat each update of an archetype as a transaction which ends once you move on to process the next archetype. This makes it easier to see the units of work which could be split over multiple threads, archetype aware tooling (e.g an editor) has an easier time to hook into "begin/end transaction", and (similar to the editor) it's easier to dynamically handle different paths for different archetypes that match a given query. I'd argue this is more friendly as they can write the same scalar-style code with the difference being just a multi-item for loop over component slices rather than a while loop. The same applies to `forEach`.

The user can always make a single-item-iterator from the chunk API themselves if they need one but they have to justify such a change and it's effect on performance of their application as one-item-at-a-time is further removed from the problem at hand where many-at-a-time is the default for archetype style ECS (the single-item iterator API communicates the wrong mental model if that makes sense?).

[1]: https://gist.github.com/tauoverpi/89c506dda247a2848cda46dfc9...

[2]: https://gist.github.com/tauoverpi/6f4832a406e49ad112a88395fa...

[3]: https://codeberg.org/tauoverpi/game/src/commit/f9dc913a805dc...

[4]: https://codeberg.org/tauoverpi/game/src/commit/f9dc913a805dc...

[5]: https://codeberg.org/tauoverpi/game/src/commit/f9dc913a805dc...