From: =?windows-1252?Q?JOAQUIN_LOPEZ_MU=3FZ?= <joaquin@tid.es>

De: Rob Stewart <stewart@sig.com>

...

...

...

Why not just "index::list?"

"list" seems too terse to me. It could lead the reader to think it is some sort of container (which is not). Take into account the namespace can be populated in the future with other containers derived from the main one.

I suppose in a given use case, a "using boost::index" (or "using boost::multi_index") may be in force, so it would boil down to just "list."

However, neither "index_list" nor "list" really says the right thing. How about turning it around: list_index?

I don't get how list_index is more meaningful than index_list. I mean, index_list is a list (a typelist, actually) of indices (index specifiers, actually). Would you care to ellaborate? (thanx!)

Chalk it up to a brain fart. I was not paying enough attention. Now that I am, what about changing it to "indexes" or "indices" according to your preference? IOW, I don't think "list" needs to be part of the name at all. That name works fine regardless of whether it is elaborated.

...

...

from my part here. There's still the pending issue of whether to move into boost::container.

I think the argument that "a" container library has to be the first one is valid, but was there sufficient consensus that such a namespace was warranted? If there is consensus, your library is a perfect candidate. If there isn't, it would be painful to put your library in the "container" namespace only to rip it out later. If you don't do it and folks agree it is worthwhile, then yours would be just one more library to move into the namespace at that time.

Well, it's all about not wasting effort. Hopefully, some other boosters (and the authors of container libraries in Boost) will jump in and express themselves for a

That will be ideal. I wasn't paying attention, but has this been addressed in a separate thread with an appropriate subject in order to garner their involvement?

On a more philosophical level, I don't quite like the idea of 1st level namespaces per se. IMHO, these are the most plausible justifications for this kind of namespaces:

1. Help avoid pollution of boost namespace. 2. Group libraries semantically affine. 3. Group libraries that will be likely used in cooperation in many programs.

As for 1, I don't see any danger of namespace pollution in Boost since libraries are accepted one by one and these things are carefully checked before.

Reasonable, but it puts the onus on each new library to avoid its predecessors.

As for 3, I don't really think that a program using an indexed_set will get a greater chance of using also multi_array, for instance (on the

Agreed.

2 is an aesthetical issue. I don't see any practical benefit from having this kind of grouping. One does not discover new libraries by way of exploring the "sourrounding" namespaces, so to say. If anything, the categorized lib index in Boost serves this purpose well.

You're partially correct. First, grouping related libraries under a single namespace means that it is a well known namespace with many things beneath its wings and yet it doesn't pollute the main namespace with all of those names. IOW, it carves out a large chunk of names and separates them and it relates those names. Is it necessary to separate them? Perhaps not now, but it probably neatly resolves tensions other library authors have felt in the past. Does grouping the names serve a purpose? Sure. If you're looking for something related to containers, the "containers" namespace seems a likely place to look. It's a discriminator that effects a binary search. It can even help with the library index to which you referred because, as the list grows longer, it becomes increasingly difficult to find the library you want. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;