Repository navigation
[atomic.ref.generic] Issues regarding P3323R1 #7556
Description
Activity
This feels non-editorial.
The suggestion for integral and floating point specializations seems fine.
The suggested wording for pointers seems wrong. It could be read as saying that for all pointer types (including function pointers and void pointers) there are operations appropriate to object pointers, i.e. arithmetic would be possible on all pointer types. That is not the intention (as was classified by an old lwg issue).
Reacted by A. JiangThe general concerns here seem well-founded, but this is not something that can be fixed editorially.
Please submit an LWG issue; see here: https://isocpp.org/std/submit-issue
Reacted by A. Jiang- addedlwgIssue must be reviewed by LWG.Issue must be reviewed by LWG.not-editorialIssue is not deemed editorial; the editorial issue is kept open for tracking.Issue is not deemed editorial; the editorial issue is kept open for tracking.
on Jan 10, 2025 This paragraph seems to identify the pointer specializations as explicit (full) specializations, but it is impossible to enumerate all pointer(-to-object) types.
I don't agree on this... But the currently wording in [atomics.ref.pointer] says
Line 3913 in 9401d5f
template<class T> struct atomic_ref<@\placeholder{pointer-type}@> { which is clearly wrong.
Also, the synopsis in [atomics.syn] was mistakenly left unchanged.
Lines 2423 to 2424 in 9401d5f
// \ref{atomics.ref.pointer}, partial specialization for pointers template<class T> struct atomic_ref<T*>; // freestanding The wording also implies that pointer-to-function types should match the main template, which is currently not the case. Currently, pointer-to-function types match the partial specialization, and such specializations can invoke the member functions that are also provided in the main template (the additional operations are guarded by [atomics.ref.pointer] p6). We should not change this.
I don't see why we shouldn't change this. It's probably a deliberate design change.
Some (if not all) concerns are addressed by #8309.
See also [format.formatter.spec]/3, which describe every such
enable_nonlocking_formatter_optimizationspecialization as a full specialization. However, we can't implement all of them as full specializations.I think the apparent unimplementability is not a defect. It might be an issue whether certain kinds of program-defined partial specializations are valid.
LWG4571 should address this.
Issue 1: The paper adds this paragraph to multiple sections:
For the main template, it is OK, but there are issues with the (partial) specializations:
T, sois_volatile_v<T>cannot be well-formed.Trefers to the pointed-to type, testing whether it is volatile is definitely not the intention of the author.Issue 2: The paper adds this paragraph to [atomics.ref.pointer]:
This paragraph seems to identify the pointer specializations as explicit (full) specializations, but it is impossible to enumerate all pointer(-to-object) types. The wording also implies that pointer-to-function types should match the main template, which is currently not the case. Currently, pointer-to-function types match the partial specialization, and such specializations can invoke the member functions that are also provided in the main template (the additional operations are guarded by [atomics.ref.pointer] p6). We should not change this.
We should keep the partial specialization, and we need to redefine
atomic_ref<pointer-type>to make use of the template parameterT.Suggested resolution (I can file a PR if CWG agrees with this direction):
is_volatile_v<T>withis_volatile_v<integral-type>.is_volatile_v<T>withis_volatile_v<floating-point-type>.is_volatile_v<T>withis_volatile_v<pointer-type>.