On Mon, 22 May 2023 at 12:10, Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
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

Right, on gcc this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96996

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).