Cleanup "partial specializations" language in [atomics.syn] #1335
Conversation
| @@ -154,7 +154,7 @@ | |||
| @\placeholdernc{integral}@ atomic_fetch_xor_explicit(volatile @\placeholder{atomic-integral}@*@\itcorr[-1]@, @\placeholdernc{integral}@, memory_order) noexcept; | |||
| @\placeholdernc{integral}@ atomic_fetch_xor_explicit(@\placeholder{atomic-integral}@*@\itcorr[-1]@, @\placeholdernc{integral}@, memory_order) noexcept; | |||
|
|
|||
| // \ref{atomics.types.operations.pointer}, partial specializations for pointers | |||
| // \ref{atomics.types.operations.pointer}, nonmember overloads for atomic<T*> | |||
There was a problem hiding this comment.
This should say non-member, with a hyphen.
There was a problem hiding this comment.
Yes, see "Spelling Conventions" in our wiki:
https://github.com/cplusplus/draft/wiki/Specification-Style-Guidelines
| @@ -154,7 +154,7 @@ | |||
| @\placeholdernc{integral}@ atomic_fetch_xor_explicit(volatile @\placeholder{atomic-integral}@*@\itcorr[-1]@, @\placeholdernc{integral}@, memory_order) noexcept; | |||
| @\placeholdernc{integral}@ atomic_fetch_xor_explicit(@\placeholder{atomic-integral}@*@\itcorr[-1]@, @\placeholdernc{integral}@, memory_order) noexcept; | |||
|
|
|||
| // \ref{atomics.types.operations.pointer}, partial specializations for pointers | |||
| // \ref{atomics.types.operations.pointer}, nonmember overloads for atomic<T*> | |||
| template <class T> | |||
There was a problem hiding this comment.
29.6.4 [atomics.types.operations.pointer] is the section referred to, and it also talks about partial specializations. These should be fixed together.
| @@ -798,7 +798,7 @@ | |||
|
|
|||
| \pnum | |||
| The implementation shall provide the function template specializations | |||
There was a problem hiding this comment.
Think we need to strike "specializations" here.
There was a problem hiding this comment.
Err, replace "function template specializations" with "function templates."
There was a problem hiding this comment.
Yes.
In any case, these provisions are mostly vacuous. We have general wording in the library front matter that says exactly that: If the standard shows a signature, the implementation is required to provide a definition for it. I'd also appreciate a cleanup of the funny "integral-type" descriptions. I'm not totally clear when the text here prescribes a non-template overload or a (full) specialization of a function template. But that's for another day.
There was a problem hiding this comment.
@jensmaurer As far as I can tell only the atomic_fetch_KEY and atomic_fetch_KEY_explicit nonmembers need to be explicit specializations. Although the wording that allows them to be mapped to a base class of atomic means it might be unobservable, because the user can't name the base class (and so can't take its address).
|
Could you please squash the commits (i.e. make them a single commit)? Thanks. |
|
(@jensmaurer: If the whole change goes into a single commit, we can also squash it at merge time these days. It's still nice if authors prepare PRs in a way that's ready as is, but it's not longer strictly mandatory.) |
|
@tkoeppe: Ok. However: Maybe I haven't found the right button yet, but I'd appreciate to see the net change for this pull request, and all I'm seeing appear to be partial changes. |
They aren't partial specializations -- there are no partial specializations of function templates.