On Wednesday, 29 August 2018 at 17:15:15 UTC, H. S. Teoh wrote:
Besides, this is missing the point. What I meant was that if
const could be arbitrarily overridden anywhere down the call
chain, then the compiler could no longer feasibly verify that a
particular piece of code doesn't violate const. The code could
be calling a function for which the compiler has no source
code, and who knows what that function might do. It could
override const and modify the data willy-nilly, and if the
const reference is pointing to an immutable object, you're in
UB land.
Not allowing const to be overridden (without the user
deliberately treading into UB land by casting it away) allows
the compiler to statically check that the code doesn't actually
modify a const object.
You appear to be thinking I was making a statement about
verifying program correctness in general, which is taking what
I said out of context.
T
You keep saying that, it has to be machine verifiable, but
honestly I don't see the benefit to being machine verifiable. As
in the case it can't verify the object doesn't change in scope at
all, it can only verify that the code in scope doesn't modify it.
I'd rather have C++ const and be useful than avoiding const
almost completely.
