Opened 15 years ago

Closed 15 years ago

#1492 closed Bugs (fixed)

Request to remove move() from top level boost namespace

Reported by: mat-lists@… Owned by: Anthony Williams
Milestone: Boost 1.35.0 Component: threads
Version: Boost Development Trunk Severity: Problem
Keywords: move top level namespace Cc:

Description

From the boost list:

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?

Joel de Guzman responded: "... I consider it a bug that should be fixed."

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 :-)"

Change History (1)

comment:1 by Anthony Williams, 15 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.