This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 28.3 [localization] Status: CD1 Submitter: Beman Dawes Opened: 2005-01-10 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [localization].
View all issues with CD1 status.
Discussion:
It appears that there are no requirements specified for many of the template parameters in clause 22. It looks like this issue has never come up, except perhaps for Facet.
Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions], either, which is the wording that allows requirements on template parameters to be identified by name.
So one issue is that 17.3.2.1 [lib.type.descriptions] Should be changed to cover clause 22. A better change, which will cover us in the future, would be to say that it applies to all the library clauses. Then if a template gets added to any library clause we are covered.
charT, InputIterator, and other names with requirements defined elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix. But there are a few template arguments names which I don't think have requirements given elsewhere:
Proposed resolution:
Change 16.3.3.3 [type.descriptions], paragraph 1, from:
The Requirements subclauses may describe names that are used to specify constraints on template arguments.153) These names are used in clauses 20, 23, 25, and 26 to describe the types that may be supplied as arguments by a C++ program when instantiating template components from the library.
to:
The Requirements subclauses may describe names that are used to specify constraints on template arguments.153) These names are used in library clauses to describe the types that may be supplied as arguments by a C++ program when instantiating template components from the library.
In the front matter of class 22, locales, add:
Template parameter types internT and externT shall meet the requirements of charT (described in 27 [strings]).
Rationale:
Again, a blanket clause isn't blanket enough. Also, we've got a couple of names that we don't have blanket requirement statements for. The only issue is what to do about stateT. This wording is thin, but probably adequate.