Section: 99 [concept.transform] Status: NAD Concepts Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [concept.transform].
View all issues with NAD Concepts status.
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.5 [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.
Change 99 [concept.transform] p2:
programshall not provide concept maps for any concept in 20.1.1.
Change [concept.true] p2:
-2- Requires: a
programshall not provide a concept map for the True concept.
Change [concept.classify] p2:
-2- Requires: a
programshall not provide concept maps for any concept in this section.