Date: Sun, 2 Jul 2023 09:04:39 -0300
Ok, so if the goal is to act as linting, I'll speak from my experience
using this kind of class on a large codebase for years now.
This would not have caught a single bug, because all bugs related to
mutability were indirect.
We had Synchronized<T> in which T calls some other type, which calls some
other type, which has a mutable member without proper synchronization.
I can give you that std::contains_mutable might be useful for something.
But std::contains_nonatomic_mutable is just trying to workaround the false
violations that you just said could be fixed by using the Override thing.
By that logic we should have the std::contains_non_synchronized_mutable, or
the std::contains_non_const_pointer, or the
std::accesses_non_synchonized_static...
Even with just std::contains_mutable, I don't think I would use it. Imagine
having to change all users of your T (to add the Override) just because you
changed the implementation and added a synchronized mutable? Doesn't make
much sense to me.
That's just my opinion though.
Best Regards,
Breno G.
On Sun, Jul 2, 2023 at 7:07 AM Frederick Virchanza Gotham via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> On Sun, Jul 2, 2023 at 1:26 AM Breno Guimarães wrote:
> >
> > I think the point folks are trying to make here is: Mutability doesn't
> imply anything for thread-safety.
>
>
> Lots of compiler warnings/errors are for catching common programming
> errors. Sometimes we get false positives, and in some cases we've even
> devised ways of abating these false positives, for example by casting
> to (void), or by putting double parentheses around an assignment in a
> conditional.
>
> Classes such as 'boost::synchronized_value' and also my own
> 'Reservable' are generic templates intended to be used for a wide
> variety of purposes for all kinds of classes. It would make sense to
> build in some compiler warnings/errors, even if they produce false
> positives occasionally, such as:
>
> template <class T>
> requires ( false == std::contains_nonatomic_mutable<T> )
> class Reservable_CanReadOnly {
> };
>
> The compiler error produced by this would be very helpful if T
> contains a mutable non-atomic member. If the programmer is absolutely
> certain that they know what they're doing, then they can use
> 'Reservable_CanReadOnly_Override' instead of 'Reservable_CanReadOnly',
> defined as follows:
>
> template <class T>
> class Reservable_CanReadOnly_Base {
> /* implementation goes here */
> };
>
> template <class T>
> requires ( false == std::contains_nonatomic_mutable<T> )
> class Reservable_CanReadOnly : public Reservable_CanReadOnly_Base<T> {
> };
>
> template <class T>
> using Reservable_CanReadOnly_Override = Reservable_CanReadOnly_Base<T>;
>
> We could make templates more safe, and avoid the introduction of
> subtle bugs, by providing in <type_traits> the following two:
>
> std::contains_mutable
> std::contains_nonatomic_mutable
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
using this kind of class on a large codebase for years now.
This would not have caught a single bug, because all bugs related to
mutability were indirect.
We had Synchronized<T> in which T calls some other type, which calls some
other type, which has a mutable member without proper synchronization.
I can give you that std::contains_mutable might be useful for something.
But std::contains_nonatomic_mutable is just trying to workaround the false
violations that you just said could be fixed by using the Override thing.
By that logic we should have the std::contains_non_synchronized_mutable, or
the std::contains_non_const_pointer, or the
std::accesses_non_synchonized_static...
Even with just std::contains_mutable, I don't think I would use it. Imagine
having to change all users of your T (to add the Override) just because you
changed the implementation and added a synchronized mutable? Doesn't make
much sense to me.
That's just my opinion though.
Best Regards,
Breno G.
On Sun, Jul 2, 2023 at 7:07 AM Frederick Virchanza Gotham via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> On Sun, Jul 2, 2023 at 1:26 AM Breno Guimarães wrote:
> >
> > I think the point folks are trying to make here is: Mutability doesn't
> imply anything for thread-safety.
>
>
> Lots of compiler warnings/errors are for catching common programming
> errors. Sometimes we get false positives, and in some cases we've even
> devised ways of abating these false positives, for example by casting
> to (void), or by putting double parentheses around an assignment in a
> conditional.
>
> Classes such as 'boost::synchronized_value' and also my own
> 'Reservable' are generic templates intended to be used for a wide
> variety of purposes for all kinds of classes. It would make sense to
> build in some compiler warnings/errors, even if they produce false
> positives occasionally, such as:
>
> template <class T>
> requires ( false == std::contains_nonatomic_mutable<T> )
> class Reservable_CanReadOnly {
> };
>
> The compiler error produced by this would be very helpful if T
> contains a mutable non-atomic member. If the programmer is absolutely
> certain that they know what they're doing, then they can use
> 'Reservable_CanReadOnly_Override' instead of 'Reservable_CanReadOnly',
> defined as follows:
>
> template <class T>
> class Reservable_CanReadOnly_Base {
> /* implementation goes here */
> };
>
> template <class T>
> requires ( false == std::contains_nonatomic_mutable<T> )
> class Reservable_CanReadOnly : public Reservable_CanReadOnly_Base<T> {
> };
>
> template <class T>
> using Reservable_CanReadOnly_Override = Reservable_CanReadOnly_Base<T>;
>
> We could make templates more safe, and avoid the introduction of
> subtle bugs, by providing in <type_traits> the following two:
>
> std::contains_mutable
> std::contains_nonatomic_mutable
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2023-07-02 12:04:52