Re: [boost] [RFC] Header/namespace policy draft

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2007-12-01 02:58:03

On Nov 30, 2007 8:47 PM, Joel de Guzman <joel_at_[hidden]> wrote:
> Hi,
>
> As promised, here's a draft of the proposed
> "Boost Header And Namespace Policy" (attached)
> Comments, suggestions, etc. very welcome.

[snip]

> The concept of "core library" is not new. boost::shared_ptr, for
> example, is a core library. It's pretty much common to all libraries.
> Having a core library gives us structure. Typically, "core" libraries
> have the highest number of dependencies. Looking at the dependency
> diagram of boost, the core libraries will be at the bottommost with
> lots of other libraries pointing acyclically at it. It's a must to
> avoid having them depend on other libraries in other layers above the
> core. More emphasis and constraints must be given to these "core"
> libraries as they form the backbone of boost as a whole. For instance,
> a broken core library will have disastrous effects on the whole Boost
> library --core libraries should be very stable.
>
> Determining wether a library is core can be part of the review. If the
> author of a library intends it to be a "core" library, he can
> explicitly say so and be subject for the review. A core library will
> have to accept more stringent requirements such as stability and
> non-dependence on other non-core libraries.
[snip]

This raises an interesting question for me. I recently received a bug
report against boost-dependent library that I work on (Adobe Source
Libraries). One of our components supports move semantics. It makes
use of a free function named move in namespace adobe. We were calling
it unqualified from within other library routines. With boost 1.35
this will have to change. Why? Because some classes in the adobe
library inherit from boost::equality_comparable. As a result, when
adobe::move is called with such boost-derived classes, ADL pulls in
the boost namespace and an ambiguity arises against the boost::move
supplied by boost::thread. One might argue that best practice in the
face of ADL is to be defensive and to avoid unqualified calls (when
replaceability is not the intent). In fact, I will do just this for
our next release.  However this would be a little bit more pleasant if
thread's boost::move was intended as a documented boost-wide
move-semantics component. In fact we might consider dropping our own
move component if such a boost component existed. At present however,
it appears that the boost::move is more of a detail of boost/thread.
Are we sure that now is the time to put move in the top level boost
namespace?

Thoughts?
 Mat