* Standardizing `__restrict__` (which C has, and C++ doesn't). Everybody relies on the compilers offering it as an extension, as without it - performance often suffers very badly.
* Universal call syntax (i.e. equivalence of `foo(myobj, myparam)` and `myobj.foo(myparam)` ). There were what I considered to be rather trivial objections, last decade, then it somehow went away.
I've found the lack of alias guarantees to be far more bark than bite. What's the primary use case? For automatic vectorization? Ultimately the only cost to check is an integer add and an integer comparison. Yeah, aliasing guarantees would eliminate those two ops (and eliminate generating the aliased version's code path). But in general, it isn't some 8x monumental cost that many people think it is.
> What's the primary use case? For automatic vectorization?
No. Without aliasing guarantees, every load via a by-ref/by-addr input param after a store via another such param must actually be executed. So either you manually cache your accesses, or you can't do loop unrolling, strength reductions, and possibly other optimization work.
> Ultimately the only cost to check is an integer add and an integer comparison
1. Manually checking that will likely not affect the compiler. Again, you can implement your own optimizations, but that's not what you want to do.
2. The interest is also for the _definition_ side of things, not just for the implementation. I want to tell the user of my function "pass unaliased arguments". This is important, because otherwise you have to provide a bunch of convoluted implementations for the case of there _being_ aliasing - which often changes the semantics of the function to something you had no intention of writing.
3. In real life, there is no guarantee that memory ranges with disjoint addresses are not aliases of the same region. There's probably no such guarantee that the standard makes, but IANALL.
* Standardizing `__restrict__` (which C has, and C++ doesn't). Everybody relies on the compilers offering it as an extension, as without it - performance often suffers very badly.
* Universal call syntax (i.e. equivalence of `foo(myobj, myparam)` and `myobj.foo(myparam)` ). There were what I considered to be rather trivial objections, last decade, then it somehow went away.