> C implementors and standards people went down this road a long time ago I'm aware of that, but just because something was done before doesn't justify it bein

> C implementors and standards people went down this road a long time ago I'm aware of that, but just because something was done before doesn't justify it being done more aggressively in the future. This isn't really an academic or tilting-at-windmills complaint either; most existing code, for better or for worse, uses pointers more broadly than the strict sense the standard allows, and more aggressive optimizations in this area are all but guaranteed to break existing code in dangerous ways. > But staying strictly in the latter model is also not viable, as it precludes some optimizations that we really want to do. Does that really make it "not viable" though? I would counter that a strictly typed model is not viable in that it precludes optimizations I want to do, as a programmer! For example: xor linked lists, doing anything with shadowed memory, using packed structures or more generally any misaligned loads on architectures that support it (which is most of the important ones), binary search trees over pointers, parsing nearly any binary file format or network protocol without lots of memcpys... and that's just off the top of my head >this is one of the big things holding up a formal spec for Rust as well I'm not familiar with LLVM's internals, but does anything preclude these optimizations being gated by an attribute that could get set (by default) by a Rust frontend but not (by default) by C frontend? Gating with attributes is already done with e.g. __attribute__((may_alias)) so it would seem that this ought to be doable. Heck, if you give me an opt-in __attribute__((contrete_semantics)) and keep the defaults UB I'd be more than content.