It doesn't quite make sense to keep object identity at the language level. Inherently the data in the arrays cannot be the same memory of the data in the objects fields.
To get the speed up, you can't just abstract it as an access pattern because it's tied to the specific way the memory is laid out.
If you were trying to make some kind of collection type that could be queried by both row and column, you would need to store it both ways at all times and also keep both representations in sync, which also defeats the purpose, somewhat.
I feel like if you're trying to do this pattern then it doesn't make sense to also keep the objects.
Database structure in a programming language! I think I've heard this idea before but never seen it implemented. Define a table with rows and columns, give it some implementation hints and query it like "SELECT id FROM monsters WHERE alive=false" and the compiler could translate it several completely different ways depending on your layout.
I was thinking about just asking the compiler to do the expensive reshuffle when I need it to, but you could go further and expect the compiler to figure out the likely access pattern and spend the transformation budget.
Heck memory is cheap (fine was cheap) give me a data structure that amortizes writes cleverly by maintaining both SoA and AoS at the same time
Well the whole point is that memory (cache in this case) is not cheap at all. We have very little and the point is to do as little loading of what you don't care about as possible to keep the cache full of only exactly what is needed for the task.
How do you imagine it's possible to write to every SoA and every AoS and have that as cheap as only the first step?
