Hi Jason, you nearly stated my point here.  What I additionally meant, is that I understood Frederick that 'const' objects with mutable sub-object members are not 100% thread-safe vs. those without are. I understood that is the reason Frederick wants to test types for mutable member variables.  You got my point that it is more about the interface and it is the responsibility of the class, what logical properties the member functions have, e.g. whether they are reentrant. They could loose reentrancy by accessing external classes or resources, too. It is not only about the structure of the class (beside trivial examples).  To directly specify thread-safe behavior one could introduce a variable and member function modifier beside 'const' (which itself is more about single-thread behavior). Let's call this modifier 'volatile'.  There are articles written, what the good idea and intention of volatile was and why it does not work in practice.  (In the end it is (among other problems) as far as I understood again about locks, which have to possibly stay locked for more than a single member function call.  I am not sure, how happy the C++ standard  committees would be about a proposal basically stating to reintroduce volatile in the dame way as it was before removal.  I think that would be the logical conclusion of Frederick's suggestion. But perhaps not necessarily.  Best, Sebastian  -----Ursprüngliche Nachricht----- Von:Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 01.07.2023 20:52 Betreff:Re: [std-proposals] std::contains_mutable An:std-proposals_at_[hidden]; CC:Jason McKesson <jmckesson_at_[hidden]>; On Sat, Jul 1, 2023 at 2:43 PM Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote: > > On Saturday, July 1, 2023, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote: >> >> Changing a mutable counts as read-only access from the view from outside the class. >> >> You think of non-mutable const accesses to be implicitly thread-safe? >> >> You could possibly reintroduce volatile member functions as thread-safe interface? >> >> C++: Been there, tried that? > > I don't understand what you wrote there. I believe his point is that mutability is not relevant; thread-safety is. 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. So it shouldn't matter if a type has "mutable members"; what matters is whether a particular interface is declared `const` or not. If it is, then it's thread-safe. > But anyway, let's say I have two base classes: > >     Reservable_CanBeReadOnly >     Reservable_CannotBeReadOnly > > The former has two methods, 'Reserve' and 'ReserveReadOnly', while the latter only has 'Reserve'. > > So next I would have: > > template<class T> > class Reservable : public std::conditional_t< std::contains_mutable_v<T>, Reservable_CannotBeReadOnly, Reservable_CanBeReadOnly > > { > > }; > > So if T is a class that has mutable members, then you won't be able to call the 'ReserveReadOnly' method. I don't understand the relationship between your "Reservable" and `T`. That is, what does it matter to `Reservable` if `T` has mutable members? What code inside the class becomes invalid? -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals