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.

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.