Proposed resolution:

Change [concept.transform] p2:

-2- A program user shall not provide concept maps for any concept in 20.1.1.

Change [concept.true] p2:

-2- Requires: a program user 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.

[ 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.

[ 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.

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 [basic.link]p1 and makes no account of the standard library being treated differently to user written code.