This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++20 status.
Section: 16.4.5 [constraints] Status: C++20 Submitter: Tim Song Opened: 2017-03-31 Last modified: 2021-02-25
Priority: Not Prioritized
View all issues with C++20 status.
Discussion:
There's currently no rule against specializing the various _v
convenience variable templates outside of <type_traits>.
foo_v<T> should be always equal to
foo<T>::value. The correct way to influence, say,
is_placeholder_v<T> should be to specialize is_placeholder,
not is_placeholder_v. Otherwise, the editorial changes to use the
_v form to the specification would no longer be editorial but have
normative impact.
Adding a global prohibition in 16.4.5.2.1 [namespace.std] seems preferable to
adding individual prohibitions to each affected template; the PR below
carves out an exception for variable templates that are intended to be
specialized by users. As far as I know there are no such templates in
the current WP, but the Ranges TS does use them.
[2017-06-14, Moved to Tentatively Ready after 6 positive votes on c++std-lib]
Proposed resolution:
This wording is relative to N4659.
Add a paragraph to 16.4.5.2.1 [namespace.std], before p2:
-1- The behavior of a C++ program is undefined if it adds declarations or definitions to namespace
-?- The behavior of a C++ program is undefined if it declares an explicit or partial specialization of any standard library variable template, except where explicitly permitted by the specification of that variable template. -2- The behavior of a C++ program is undefined if it declares […]stdor to a namespace within namespacestdunless otherwise specified. A program may add a template specialization for any standard library template to namespacestdonly if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.(footnote: […])