Re: [boost] [Boost.Move] A few notes

Subject: Re: [boost] [Boost.Move] A few notes
From: Dan Ivy (danivy.mail_at_[hidden])
Date: 2012-01-12 16:18:43

On Thu, Jan 12, 2012 at 9:16 PM, Jeffrey Lee Hellrung, Jr.
<jeffrey.hellrung_at_[hidden]> wrote:
> All fair criticisms. However, I think this is the simplest solution. If
> BOOST_FWD_REF( T ) expanded to T&, it wouldn't bind to temporaries, making
> the call expression ugly, and unnecessarily so in the cases that true
> rvalue references are available or the type isn't even movable. In any
> event, the current forwarding solution is no worse than what we had before
> Boost.Move, so we aren't regressing in any way. If the caller really wanted
> to ensure their object got moved, there is a way to do that (bind the
> temporary and explicitly move it, or use a macro like BOOST_MOVE below);

I'd hate to repeat myself again, so this is the last time, I promise :)
I think we misunderstand each other, or at least I don't understand
you completely. You keep talking about "cases where true
rvalue-references are avaiable", but I don't see what you mean by
that? The purpose of Boost.Move is to fill in the gaps when true
rv-refs aren't available, so code using Boost.Move is, in general,
unaware of whether or not true rv-refs are avaiable. I thoght you were
talking about cases where the library writer uses Boost.Move for
portability, but the end-user is using a C++11 compiler exclusively,
and couldn't care less about these sort of things, and now he has to
uglify his code just for the sake of Boost.Move's shenanigans. But, as
I said, this is not the case. On C++11, BOOST_FWD_REF(T) is still T&&
(&&!) and would happily accept, and move, temporaries. The only issue
is about cases where protability matters. While I prefer uglier but
movable temporaries, you prefer (I think) neater but possibly
non-moveable ones. That's cool.
The regression I was talking about is when the aforementioned C++11
enthusiastics suddenly need to compile their code on a C++03 compiler,
I belive they would be upset that their program's efficency is
compronised, without being given any hint about this during
compilation (true, this is how it is right now. It doesn't mean that
it HAS to be like that.), while you think that they'll be happy that
their code compiles and runs. Again, both are valid opinions.

if
> the callee wanted to be particularly helpful, it would offer more overloads
> to accurately capture moveable temporaries (this can require up to 4 or
> more overloads and SFINAE, but it's possible).

Interesting. Could you provide a reference or an example?

>
> [...]
>
> In truth, I typically forego BOOST_FWD_REF altogether and just write
> different overload sets for "outward-looking" interfaces depending on
> BOOST_NO_RVALUE_REFERENCES. In which case BOOST_FWD2_REF is what I end up
> using more often.

So, it seems that you're already using the same thing I suggest...