This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Editorial status.
Section: 33.5 [atomics] Status: NAD Editorial Submitter: Clark Nelson Opened: 2008-12-05 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [atomics].
View all issues with NAD Editorial status.
Discussion:
Addresses US 89
The types in the table "Atomics for standard typedef types" should be typedefs, not classes. These semantics are necessary for compatibility with C.
Change the classes to typedefs.
N2427 specified different requirements for atomic analogs of fundamental integer types (such as atomic_int) and for atomic analogs of <cstdint> typedefs (such as atomic_size_t). Specifically, atomic_int et al. were specified to be distinct classes, whereas atomic_size_t et al. were specified to be typedefs. Unfortunately, in applying N2427 to the WD, that distinction was erased, and the atomic analog of every <cstdint> typedef is required to be a distinct class.
It shouldn't be required that the atomic analog of every <cstdint> typedef be a typedef for some fundamental integer type. After all, <cstdint> is supposed to provide standard names for extended integer types. So there was a problem in N2427, which certainly could have been interpreted to require that. But the status quo in the WD is even worse, because it's unambiguously wrong.
What is needed are words to require the existence of a bunch of type names, without specifying whether they are class names or typedef names.
[ Summit: ]
Change status to NAD, editorial. See US 89 comment notes above.
Direct the editor to turn the types into typedefs as proposed in the comment. Paper approved by committee used typedefs, this appears to have been introduced as an editorial change. Rationale: for compatibility with C.
Proposed resolution: