On Monday, 22 May 2023 04:22:18 PDT Edward Catmur via Std-Proposals wrote:
> Anyway, the point (nowadays) is optimization - the compiler can assume that
> opaque code does not modify a const object (or subobject).
Actually, it's the opposite. Compilers assume that const objects can be
modified through const_cast all the time...
Note how they all reload from memory: https://gcc.godbolt.org/z/YEnzMr8xP.
Even if the member itself is const: https://gcc.godbolt.org/z/xs7xhE5os
We have to be careful because we don't want to break std::optional being able to destroy and recreate its contained value even if that value has const subobjects. But here it would be UB to continue to refer to `s` if it has been destroyed and recreated externally, so the optimization is still valid.
I've been meaning to ask for a [[really_const]] attribute for a while.
It shouldn't be necessary (per the standard, implementations might want to add it anyway).