On Thu, 2025-06-12 at 13:01 +0300, Ville Voutilainen wrote:
> On Thu, 12 Jun 2025 at 11:56, Marvin Williams via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
>
> > With the above interpretation, I can see how const may imply
> > bitwise
> > const, but I fail to see how Herb derives the internal
> > synchronization
> > requirement. In my understanding, the example given at 26:00,
> > locking a
> > mutable std::mutex member still modifies the object, violating
> > [res.on.data.races], if a standard library function were to call
> > w.get_info() on a const widget& w.
>
> Locking a mutable std::mutex member doesn't count as modifying the
> object. Because it doesn't modify
> the *observable* parts of the object, it just synchronizes access to
> them, making those accesses race-free.

Is there something in the standard clarifying what exactly qualifies as
modification in this sense?
For example, would changing a private (non-atomic) int member still not
qualify as modifying? While it does not change the observable parts of
the object, it is certainly not thread-safe.

Best
Marvin

> So, it's not correct to think a fully bitwise constness is implied.
>
> You could also theoretically have various mutex-synchronized mutable
> caches in the stdlib objects. Those
> could be modified in const member functions, and that doesn't violate
> anything, such modifications are the
> whole point.