Hi, During the review of the string algorithm library, an issue was raised about the namespaces for algorithmic libraries in the boost. The issue has not been sufficiently resolved, and I would like to bring it up to the discussion again. Current proposal looks like this: boost - algorithm - common algorithm related stuff - string - string algorithms - container - container algorithm etc. Although this seems clear enough, there are some open questions. 1.) Namespace path is quite long. It is not really reasonable to await from a user to always type boost::algorithm::string::trim. "using namespace" directive is not always a viable solution. And even if it would be, a user would have to specify several of them to use whole algorithm library (what could not so uncommon, in my opinion) Namespace aliasing is one of possible solutions, but again, one would have to alias every algorithm sub namespace. 2.) It is not clear if what should go into boost::algorithm namespace and what to more specific ones (like boost::algorithm::string). This is specificaly an issue of algorithms, that logicaly belong to various categories. An example would be "all" algorithm. It is generic enough to not be contained in the string library. But on the other hand, together with classification predicate, it is essencial for the string processing. Should it go to algorithm::string, algorithm::container, plain algorithm or somewhere else? Suggestions: 1.) One possibility would be to relieve the idea of algorithm subnamespace and put everything into boost::algorithm namespace. Benefit would be simplier namespace specification and less suprises about where is a particular algorithm. Disadvantage can be a possibility of nameclashes and poluted namespace. 2.) Another option would be to use subnamespaces, but to propagate user-level interface names to boost::algorithm using "using" directive. In this alternative, there is still an open question (2). (i.e. to define more precisely the policy for putting algorithms/classes into namespaces) 3.) Let everything in subnamespaces and identifying the problem(1) as irelevant. 4.) Some other idea, I don't know yet about. Your ideas/optinions are welcome. Regards, Pavol