This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.
Section: 16.5.4 [constraints] Status: WP Submitter: Tim Song Opened: 2017-03-31 Last modified: 2017-07-30
Priority: Not Prioritized
View all issues with WP status.
There's currently no rule against specializing the various _v convenience variable templates outside of <type_traits>.There should be; 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 220.127.116.11.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]
This wording is relative to N4659.
Add a paragraph to 18.104.22.168.1 [namespace.std], before p2:
-1- The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization for any standard library template to namespace std only 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: […])-2- The behavior of a C++ program is undefined if it declares […]