I don't think any more people will join the review, so I've collected all the contributions regarding naming issues and tried to come up with a "unified" naming scheme. As it was expected, suggestions vary wildly, and the choicespan is growing as the review advances, so maybe this is a good time to try to reach a compromise. Please note everybody will have a favorite alternative, but the idea is that this proposal at least satisfies everybody and is abhorred by nobody. I'd appreciate if you take a look at the proposal and either accept it or provide strong argument against it (or against parts of it). It would help if further discussions conform more or less to the structure of this proposal, so as to ease gathering results later. Also, I'm not the review manager and it is not for me to make the final decision on this and other issues, but I think some preprocessing work could be beneficial. So: NAMESPACE * Proposal: boost::container::multi_index * Rationale: The name suggests what the library is about and does not clash with the name of the container. Preferred to multiindex as English seems to like the former better. In favor of multi_index: Rob, Pavel (underscore-less variant), Arkadiy (for the container instead), Jeff, Thorsten, Paul, Matthew (only if pushed into boost::container). Alternatives: non-descriptive name (Tom), multi_indexed_containers. * Why inside boost::container? Seems like there's a general move to 2nd level namespaces, and this in particular saves us from repeating "container" in the library namespace itself. If anything, being the only library inside boost::container does not hurt. I've scanned the posts and these are the reviewers' opinions about this subject matter: In favor of pushing into boost::container: Matthew, Joerg Against: Dave Not sure: Jeff Don't care: Gary, Darren CONTAINER NAME Proposal: composite_container. Rationale: It more or less suggests what it is. "index" does not appear in the name, but to compensate it'll show anywhere else (the namespace and the parameters like index_list) so the index concept is ubiquitous. It does not use "set" as composite_container in general is not a set. It matches the concept it'll model in the future (when this section is written.) Alternatives proposed by reviewers: indexed_set, multicontainer, indexed_table, table, indexed, composite_set, set (distinguised from std::set by the namespace). LIFTING TO NAMESPACE BOOST * Proposal: container lifted only one level: boost::container::composite_container * Rationale: Lifting to boost seems too long a jump, and lifting to both places is overkill. LIBRARY NAME * Proposal: Boost Multi-index Container Library * Proposal for short form: BMCL * Rationale: The name is descriptive enough, and gives room for future containers to be added here (indexed maps, the infamous bimap, etc.) REGULAR INDICES * Proposal: Name changed to "ordered indices". * Rationale: The name is far more descriptive. When first met, "regular" means nothing. Allows for a nice solution to the clash with std::unique (see below). INDEX NAMES * Proposal: "unique" and "non_unique" changed to "ordered_unique" and "ordered_non_unique". * Rationale: No one opposed and some liked it. Solves the clashing with std::unique. Extends nicely to hashed indices (unordered_unique etc.) It is more descriptive. In favor: Gary, Dave. Rob dislikes the unique/non_unique suffix, but alternatives do not look better IMHO. NTH_INDEX_TYPE AND FAMILIY * Proposal: nth_index<N>::type index<Tag>::type nth_index_iterator<N>::type nth_index_const_iterator<N>::type index_iterator<Tag>::type index_const_iterator<Tag>::type * Rationale: It eliminates the dreaded "_type" suffix. It does not clash with inherited "iterator" and "const_iterator" types. Two reviewers loved it (Darren, Dave), the rest said nothing about it. UPDATE MEMFUN * Proposal: Change to "replace". * Rationale: It more faithfully describes the semantics of the operation. One reviewer in favor (Dave), plus Pavel and myself. HEADER ORGANIZATION * Proposal: follow a fine-grained policy, possibly with "grouping" headers (e.g. for key extractors.) * Rationale: Seems like good style. Two reviewers favored this approach (Dave, Gary). The rest didn't care/say anything. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo