Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros

Subject: Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-05-11 02:48:00

On 5/6/2010 8:36 PM, OvermindDL1 wrote:
> Greetings Boost Developers and Users,
>
> It's my pleasure to announce that the review of Ion Gaztañagas' Move
> library starts May 10th and lasts until May 24th, 2010, unless an
> extension occurs.

First, again, I want to thank you, Ion, for putting this library 
together and listening to all the comments up to this point.  The 
documentation is very well done, as it always has been.

Also, thank you OvermindDL1 for volunteering as review manager.

Second, I have to admit that I do have some reservations with this 
incantation of the library.  I will be trying to post multiple comments 
over the next couple days, as I think of things and get around to 
expressing my ideas.

In my opinion, *the* primary goal of this library is to provide a 
standardized convention by which data structures and algorithms within 
and outside of boost can make use of move semantics in c++03 (there is 
already such a convention in c++0x).  All the macros, moving and 
forwarding functions, move iterators, etc., are, I believe, secondary to 
introducing boost::rv<T>& and what that little class is suppose to 
represent and how T should interoperate with it.  What I would like to 
see are a set of requirements for a type to be MovableCopyable, or 
MovableNoncopyable.  I'd imagine this would essentially consist of a 
conversion operator to boost::rv<T>&, constructor accepting a 
boost::rv<T>&, an assignment operator accepting a boost::rv<T>&, and the 
semantics associated with these member functions.  This means, for 
example, that, as an author of some class, I am not restricted to using 
the macros provided by this library to enable move emulation, or the 
forwarding functions this library provides, or whatever else, if they 
don't meet my requirements.  For example, one may want to only 
conditionally enable move emulation, depending on whether its member 
objects are movable or not.  Why might one not want to enable move 
emulation?  If you enable optimal emulation, you wind up with a class 
that doesn't play well with enclosing classes that don't explicitly 
define an assignment operator.  Minimizing the proliferation of such 
classes could be a good idea.  Also, if you're just gonna define copy 
assignment in terms of a copy-and-move or a copy-and-swap, there's no 
point in using optimal move emulation, since your copy assignment 
operator may as well accept by value anyway.  I'm hoping these 
considerations might convince you that there is no "one size fits all" 
macro to enable move emulation.  I believe an itemization of the 
nitty-gritty requirements that a class must satisfy to be move-aware 
will encourage alternative, more targeted methods to enable move 
emulation while remaining inter-compatible with each other.

Regarding the macro BOOST_MOVE_OPTIMIZED_EMULATION: I think this is a 
bad idea, but perhaps I'm missing something.  It seems like as soon as 
you mix in some move-enabled class into your code that *must* use the 
non-optimal move emulation (either by design, or through its interaction 
with other enclosing classes that fail to explicitly define a copy 
assignment operator), *all* your move-enabled classes will have to use 
the "safe" (i.e., non-optimal) move emulation.  The only serious use 
case I see is when BOOST_MOVE_OPTIMIZED_EMULATION is always left 
undefined.  Am I missing something?  If not, then I think we should 
either 1) offer *only* the "safe" option, for simplicity; or 2) offer 
both options as separate move emulation enabling macros.

Hopefully this will be something to at least get discussion started.

- Jeff