Hi, This is my 2nd proprosal for naming of the library formerly known as Boost.IndexedSet. I've changed my mind with respect to some of the decisions stated at my first proposal (rationale is given.) There is also a minor clashing issue that I'd want to publicize before the final commit. I list here only the points that have changed with respect to my first proposal, that you can find at: http://lists.boost.org/MailArchives/boost/msg62611.php If no one complains about this 2nd proposal I'll apply the necessary changes by the end of the following week. NAMESPACE * Proposal: boost::multi_index. This differs from the previous proposal in which boost::container is not used; rationale: resulting qualified ids would be too long, which would force most users to use namespace aliases (not a good thing, this has been discused before in connection with Boost.Filesystem) or apply using directives. Another reason is that a good deal of preexisting Boost containers don't live in boost::container and it does not seem such a migration will ever take place. CONTAINER NAME Proposal: indexed_container. Rationale: composite_container sounded too vague; indexed_container is reminiscent of the previous name indexed_set, so in a sense it won't break the (admittedly shallow) familiarity with the library that boosters might have built up so far. LIBRARY NAME: Proposal: Boost.MultiIndex. Rationale: In sync with the namespace. REST OF NAMING ISSUES: Like in the 1st proposal. NAME CLASHING ISSUE: The renaming of nth_index_type & familiy to nth_index etc. uncovered a name clashing issue in GCC (and only in this compiler AFAIK): using namespace boost::multiindex; typedef index<indexed_t,some_tag>::type index_t; //clash! The index<> class template clashes with the non-standard C-runtime function index() living in <string.h>. Unfortunately, most std headers (even C++ ones) seem to implicitly include <string.h> as well, so the clash is likely to occur. In my opinion, this clash is not important enough, for the following reason. index<...> is provided mainly as a workaround for MSVC 6.5, which has well-known problems with nested templates. In GCC one can write instead: using namespace boost::multiindex; typedef indexed_t::index<some_tag>::type index_t; using the nested index<...> variant. This is always preferrable, and does not clash in any manner with global index() in <string.h>. Of course, there are other obvious resolutions to this clashing issue. For this reason, my proposal is to effectively change index_type<...> to index<...>, and similarly with the other related template classes as previously proposed, even in the presence of this clashing issue. If someone thinks differently, please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo