This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 33.5.8 [atomics.types.generic] Status: Resolved Submitter: S. B. Tam Opened: 2016-05-24 Last modified: 2017-03-20
Priority: 3
View all other issues in [atomics.types.generic].
View all issues with Resolved status.
Discussion:
33.5.8 [atomics.types.generic] mentions 'aggregate initialization syntax'. It's unclear what it stands for, especially since atomic types are actually not aggregate types (they have user-provided constructors).
[2016-11-13, Jonathan comments and provides wording]
LWG agreed to simply strike those sentences. We believe their purpose is to require that the same syntax as C programs use is valid, e.g.
atomic_int i = { 1 };
But such syntax is already required to work by the constructor
definitions, so there is no need to require it again here with
redundant wording.
It's unnecessary to require that syntax for the atomic<T*>
specializations because they have no equivalent in C anyway (unlike
the named atomic types for integers, there are no typedefs for
atomic<T*>
).
atomic_int i = { 1 };
— end example]
[2016-11-12, Issaquah]
Sat PM: The key here is that we need to support = { ... }
JW to provide wording
[2017-03-04, Kona]
This is resolved by P0558.
Proposed resolution:
This wording is relative to N4606.
Edit 33.5.8 [atomics.types.generic] as indicated:
-5- The atomic integral specializations and the specialization
-6- There shall be pointer partial specializations of theatomic<bool>
shall have standard layout. They shall each have a trivial default constructor and a trivial destructor.They shall each support aggregate initialization syntax.atomic
class template. These specializations shall have standard layout, trivial default constructors, and trivial destructors.They shall each support aggregate initialization syntax.