What is the state of type-based noalias guarantees? (documentation/plans?)

[rohlem]

Type based aliasing analysis (aka "strict aliasing", with that inconsistent C legacy exception for u8 (but not i8?) ) was mentioned in the documentation until 8d6601d . I thought there were issues about it too, but I couldn't find them, so I guess not.
I assume the mention in the docs was only removed because it wasn't implemented yet. Does that mean it's still a planned feature?
(The main reason I'm asking is because of their interaction with @fieldParentPtr (see #1644 ), but I'd also appreciate a place to discuss whatever decision ends up manifesting towards 1.0.)

[andrewrk]

This is a really important design decision. My current plan is to experiment with "nothing is allowed to alias unless you annotate it as being able to alias" and see how doable that is. If Zig can have alias rules that are 100% caught with runtime safety in debug mode, and provide better guarantees to the optimizer than TBAA, that would be ideal.

I removed that section from the docs, because before it was planned to have TBAA; now I want to experiment with a different strategy.

The current state is that all aliasing is allowed and is safe, but that's probably going to change.

[andrewrk]

see #1108 and #476
zig will have a well defined memory model, but potentially with very strict aliasing rules, albeit not necessarily type based.