(I’m sympathetic to the concern of things breaking in unexpected ways.)
For instance Zig has a MultiArrayList container in its stdlib which slices its generic item type into one array for each struct item. This isn't a special compiler feature, but a regular usage of Zig's comptime stuff:
https://github.com/ziglang/zig/blob/master/lib/std/multi_arr...
On the other hand, giving up that control and designing languages where more automatic optimizations are possible also seems really great. A lot of programming shouldn’t be concerned with low level perf anymore.
> Compilers really shouldn't do this under the hood, it adds more complexity to the compiler [...] Instead [...] like [...] SoA
Curious. I read GP as "I really want to be able to tell compilers to make these changes", but with exception of your SoA example, all (5) responses assumed it was a desire for a sufficiently magical black-box optimizer. Which in retrospect seems plausible, but first seemed to me quite odd. Of course you want to be able to slap in a paragraph of Halide, or annotate with memory organization... <puzzled expression>. Too much time thinking metaprogramming open compilers and inline multilingualism.
Instead these should be explicit programming language features (like defining a regular struct but then slice this struct into an SoA).
The rest should be handled by debugging and profiling tools which need to be much better integrated into the programming workflow than what is common today.