Proposed resolution:

Change [res.on.headers], Headers, paragraph 1, as indicated:

A C++ header may include other C++ headers.^[footnote] A C++ header shall provide the declarations and definitions that appear in its synopsis ([basic.def.odr]). A C++ header shown in its synopsis as including other C++ headers shall provide the same declarations and definitions as if those other headers were included.

^[footnote] C++ headers must include a C++ header that contains any needed definition (3.2).

[ 2009-07 Frankfurt: ]

Revised Proposed Resolution:

A C++ header may include other C++ headers. A C++ header shall provide the declarations and definitions that appear in its synopsis (3.2 [basic.def.odr]). A C++ header shown in its synopsis as including other C++ headers shall provide the declarations and definitions that appear in the synopses of those other headers.

Alisdair: Does this address the BSI comment?

Beman: There were several overlapping comments. I tried to handle them all with one resolution.

Alisdair: I'd prefer to see this closed as NAD and have this resolution be the subject of some other, new issue.

Move to NAD Concepts. Howard to open a new issue (1178) in Ready state with the Proposed Resolution above. Beman will write up a discussion for the new issue.

[ 2009-07-17 Beman updated the proposed resolution based on feedback from the LWG in Frankfurt: ]

• Strike two pieces of text considered unnecessary.
• Change "definitions" to "declarations and definitions" in two places.
• Wording tightened slightly.

[ 2009-07-15 Beman updated the proposed resolution: ]

[ 2009-06-16 Beman updated the proposed resolution: ]

• The mechanism is no longer specified, as requested in Batavia.
• The footnote has been removed since it specified mechanism and also did not reflect existing practice.
• A sentence was added that makes it clear that the existing practice is permitted.

[ Batavia (2009-05): ]

Pete believes the proposed wording overconstrains implementers. Instead of specifying the mechanism, he prefers a solution that spells out what needs to be declared, rather than how those declarations are to be provided, e.g.,

A C++ header shall provide the names that are required to be defined in that header.

Bill suggests approaching the wording from a programmer's perspective. We may want to consider promising that certain widely-used headers (e.g., the concept headers) are included when needed by other headers. He feels, however, there is nothing broken now, although we may want to consider "something nicer."

Move to Open status.

[ Beman provided the proposed resolution for the May 2009 mailing. He comments: ]

Initially I tried to specify exactly what header should include what other headers. This was verbose, error prone, hard to maintain, and appeared to add little value compared to just stating the general rule.

[ Ganesh adds: ]

The same problems exists for <memory_concepts> and <container_concepts>.

In order to compile <vector> you just need the definitions of the concepts in <memory_concepts>, the concept maps defined there are not necessary. Yet, from the user point of view, if the concept map template for AllocatableElement are not in scope, <vector> is pretty useless. Same for <tuple> and ConstructibleWithAllocator.

Similarly, <queue> is not very useful if the concept map template for QueueLikeContainer is not in scope, although the definition of concept alone is theoretically sufficient.

There's a pattern here: if a concept has concept maps "attached", they should never be separated.

Addresses UK 78

Related to 1063.

This is effectively an extension of LWG issue 343.

We know there is an increasing trend (encouraged by conformance testers and some users) that each library header should supply no more than required to satisfy the synopsis in the standard. This is typically achieved by breaking larger headers into smaller subsets, and judicious use of forward declarations.

If we apply this policy to C++0x (per N2800) it will be very surprising for people using library algorithms over ranges defined by pointers that they must #include <iterator_concepts> for their code to compile again. That is because pointers do not satisfy any of the iterator concepts without the concept_map supplied in this header.

Therefore, I suggest we should require all library headers that make use of iterator concepts are specifically required to #include <iterator_concepts>.

At a minimum, the list of headers would be: (assuming all are constrained by concepts)

algorithm
array
deque
forward_list
initializer_list
iterator
locale
list
map
memory          // if 1029 is adopted
memory_concepts
numeric
random
regex
set
string
tuple
unordered_map
unordered_set
utility
vector