"The point about const is not wrong. What you said about const is true if, and only if, the object was originally const - i.e. you can't do this:" That's what

"The point about const is not wrong. What you said about const is true if, and only if, the object was originally const - i.e. you can't do this:" That's what i said, actually: " Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue both result in undefined behavior. So yeah." "he other problem is that C++ (but not C, thanks to "restrict") lacks a way to say "the object referenced by this pointer or reference is not aliased in any other respect that matters to this function"." "In C++, they can only optimize as well when the compiler can do a full program analysis" Which is why i said anyone who cares hands it the whole program anyway. Because even in rust, not having the whole program but claiming to pretend about performance is just silly. "I care tremendously about performance, but i refuse to give you enough of the program for you to do anything with it :P" That said, you can actually do it without fully program analysis. It suffices to have summaries. " and determine that the referenced value is immutable in practice. Which can be hard to do for non-trivial programs, " With no offense, this isn't the early 2000's anymore. Whole program LTO is not some esoteric feature, it's the default for anyone who actually cares about performance. Same with the type of mod/ref analysis you are talking about. It's done already. We whole program optimize binaries with hundreds of millions of lines of code in them. So do plenty of people. It also doesn't actually require full program,only the ability to see the allocation site and the call. It doesn't have to prove it's always immutable, if it can prove it at least once it can just specialize that function (and do so in a way that it would be reused with anywhere else that specializes). But yes, you could also try to prove it is always immutable (and gcc does that too). " and outright impossible to do across dynamic library boundaries." This is actually not right, though admittedly not common, fwiw. First, you can summarize it, and include it in a section of the .so, assuming you are just doing dynamic linking. If you are doing dynamic loading, yes, you'd need to JIT it. But still doable. (i won't point out that dynamic loading is not actually legal in any of these languages :P)