On Sat, Jul 1, 2023 at 7:52 PM Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> If a member function is `const`, it could still technically modify
> `mutable` members. But that doesn't matter; by marking it `const`, you
> are de-facto claiming that calling this function on the same object
> from multiple threads is 100% OK. And if you're doing modifiable
> accesses, it is that function's job to *make it* OK.


A few weeks ago I posted on this mailing list about how I was adding
elements to a set, and then later I wanted to change some of the
elements (without affecting the equality or order of the elements in
the set). So I had something like:

    std::set< std::pair<uint64_t, bool> > g_container;

So I would add something like { 6782u, false } to the set, and then
later I would change the boolean to true.

Arthur responded to say that I should do the following:

struct Monkey {
    uint64_t number;
    mutable bool is_valid;
};

std::set< Monkey > g_container;

In this example, the 'Monkey' class would malfunction if were to try
to do "Reservable::ReserveReadOnly.()". I would have a synchronisation
issue on the non-atomic boolean if it were to be edited when a
shared_mutex is locked in shared mode.