On Thu, Jan 12, 2012 at 9:16 PM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> 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...