On Mon, 22 May 2023 at 12:10, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> 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).