On Sun, 13 Oct 2024 at 18:59, Giuseppe D'Angelo
<giuseppe.dang...@kdab.com> wrote:
>
> Hello,
>
> On 11/10/2024 21:43, Jonathan Wakely wrote:
>
> > Or alternatively, and arguably simpler, we could get rid of the ugly
> > _GLIBCXX20_INIT macro and just do this:
> > +#if __cpp_lib_atomic_value_initialization
> > + atomic() noexcept (is_nothrow_default_constructible_v<_Tp>)
> > + requires (is_default_constructible_v<_Tp>)
> > + : _M_i() { }
> > +#else
> > atomic() = default;
> > +#endif
> > ~atomic() noexcept = default;
> > atomic(const atomic&) = delete;
> > atomic& operator=(const atomic&) = delete;
>
> This is now basically my original patch :) but it does correctly not
> value-initialize _M_i in pre-C++20 modes -- my bad, I didn't realize
> that P0883R2 was *not* meant to be treated as a DR and backported.
There was a related issue:
https://cplusplus.github.io/LWG/issue2334
Do you know what other implementations do?
>
> > This more closely matches what's in the standard, except that we have
> > a requires-clause on the default constructor. It seems like a defect
> > that the standard doesn't do this, instead requiring
> > is_constructible<atomic<NDC>> to be true, but Mandating an error if
> > you try to use it.
>
>
> Did you mean is_default_constructible?
It's the same thing :-)
is_default_constructible<T> is defined as is_constructible<T>.
> Yes, the core of the "problem"
> seems to be the Mandates instead of the Constraints used to describe
> atomic()'s default constructor in
> https://eel.is/c++draft/atomics.types.operations#1 . I also think a
> constraint would be more natural, in line with the idea of atomic<T>
> "wrapping" a T object. I don't seem to find any rationale for this
> choice in P0883's revisions, I guess I'll just ask SG1 and/or possibly
> submit a LWG issue.
I think that would be good, thanks.
