Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

When Rust attempted to use the LLVM IR implementation underlying this feature ("noalias"), it took multiple years of work fixing LLVM, before it no longer caused miscompilations. Most of those errors were also expressible in C code -- it was not simply that Rust is a different language. How can that be, given the age of this feature? Because it's so rarely used in C or C++ that those edge cases were not discovered. But then Rust came along and used it _everywhere_.

The current LLVM implementation doesn't even represent many forms of "restrict" -- often, the information is just dropped. There's been ongoing work in LLVM since 2019 (search for "full restrict") to enhance the representation. Not yet landed.

It's also unclear what the interaction should be, or is, between restrict and C++ operations like creating a reference from a pointer. E.g. given `int* restrict y` does `int& x = *y;` count as an access to the object that could violate restrict, even if you never read `x`? Or, how about calling a non-virtual member function, where the function body doesn't reference any member variables. Does that access the "this" object in a way that would violate restrict?

You might claim that the answer is obviously "no" for both, because there's no "actual" memory accesses. But that's only true under the "C++ as portable assembly" world. Per the specification, these do nominally access the object, and the compiler takes advantage of that to reorder loads for better performance. So, maybe it is/should be a violation of restrict? I dunno, who can really say, since restrict isn't specified for C++!