I think the point folks are trying to make here is: Mutability doesn't
imply anything for thread-safety.

Thread safety (even on const methods) is a feature that a class may choose
offer or not.
It's generally considered "well-behaved" to have const methods allowed to
be called by multiple threads. This feature can be offered regardless of
the presence of mutable members.

You can have no mutable members, and yet be unsafe:
https://godbolt.org/z/vqhn1noqa
Or you can have mutable members and be safe: https://godbolt.org/z/KvcszYWT7

So I fail to see how the detection of mutability can help in the problem at
hand.

Best Regards,
Breno G.

Em sáb., 1 de jul. de 2023 19:47, Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> escreveu:

> On Sat, Jul 1, 2023 at 11:33 PM Frederick Virchanza Gotham
> <cauldwell.thomas_at_[hidden]> wrote:
> > 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.
>
>
> Actually this is why there should be two new additions to <type_traits>:
>
> std::contains_mutable
> std::contains_nonatomic_mutable
>
> The former will be true for any class that has a mutable member. The
> latter will be true for any class that has a mutable member but only
> if the mutable member is non-atomic.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>