This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Concepts status.
Section: 99 [concept.transform] Status: NAD Concepts Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [concept.transform].
View all issues with NAD Concepts status.
Discussion:
Addresses UK 199
The requirement that programs do not supply concept_maps should probably be users do not supply their own concept_map specializations. The program will almost certainly supply concept_maps - the standard itself supplies a specialization for RvalueOf references. Note that the term program is defined in 6.6 [basic.link]p1 and makes no account of the standard library being treated differently to user written code.
[ 2009-05-09 Alisdair adds: ]
The same problem is present in the words added for the LvalueReference/RvalueReference concepts last meeting.
With three subsections requiring the same constraint, I'm wondering if there is a better way to organise this section. Possible 20.2.1 -> 20.2.3 belong in the fundamental concepts clause in [concept.support]? While they can be implemented purely as a library feature without additional compiler support, they are pretty fundamental and we want the same restriction on user-concept maps as is mandated there.
[ Batavia (2009-05): ]
We agree with the issue, but believe the wording needs further improvement. We want to investigate current definitions for nomenclature such as "user" and "program." Move to Open pending the recommended investigation.
Proposed resolution:
Change 99 [concept.transform] p2:
-2- A
programuser shall not provide concept maps for any concept in 20.1.1.
Change [concept.true] p2:
-2- Requires: a
programuser shall not provide a concept map for the True concept.
Change [concept.classify] p2:
-2- Requires: a
programuser shall not provide concept maps for any concept in this section.