https://svn.boost.org/trac10/ticket/1492 <p> From the boost list: </p> <p> Mat Marcus wrote: 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? </p> <p> Joel de Guzman responded: "... I consider it a bug that should be fixed." </p> <p> John Maddock responded: "100% agreement from me: "move" is such a common name that we can't afford to pollute namespace boost with it: unless we really mean to of course :-)" </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/1492 Trac 1.4.3 Anthony Williams Tue, 04 Dec 2007 09:15:54 GMT https://svn.boost.org/trac10/ticket/1492#comment:1 https://svn.boost.org/trac10/ticket/1492#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> Ticket