Eric Niebler wrote: -- snip 2^10 overloads -- Yeah, that's probably too much, but I'm not sure we have to support forwarding for that many arguments. The only thing rvalue forwarding buys you (and it can be a big win) is the ability for the wrapped thing to make certain optimizations. It's a good idea when you can do it. If you can't do it, you can fall back to lvalues and in C++03 you've still done a credible job.
David Abrahams wrote:
Can you show me an example of a "sound" function that treats a const rvalue differently from an lvalue, please?
fusion::make_vector(), for instance. It returns a fusion::vector<> where the members can be held by value or by reference. Getting it wrong can lead to dangling references. Proto has similar function objects that need to be careful about the lifetime of temporaries.
I'm a little confused. Proper rvalue detection for *wrapper functions* or not, we have no way of writing make_vector so that it stores all rvalues and references lvalues. So in C++03, that function needs some hints about when to store values. I'm not convinced it doesn't need those hints in C++0x. After all, any time you build a vector of references from lvalues, those references (or copies thereof) can be made to dangle. That doesn't mean a wrapper function should not forward non-const rvalues to its wrapee.
It wouldn't be useful for my purposes. What I took from the discussion about result_of and C++03 was that, for a function object that cares about lvalue/rvalue-ness to work consistently across C++03 and C++0x, assuming rvalue-ness and opting in for lvalue-ness with reference_wrapper<> is really the only option. But if you have an insight, I'd be happy to reopen that discussion. It was rather unsatisfying last time.
I just think that since you don't have permission to mutate a const rvalue anyway, forwarding it as a const reference doesn't really hurt anyone.
When I've gotten it wrong, it hurts.
Maybe you're making assumptions that you really can't afford to make (that storing a reference to an lvalue, even when properly detected, is a good idea).
If we give up on backwards compatibility, a merger is still possible. I think Joel's suggestion is workable. I like the approach he and Hartmut are using in the Spirit 2 transition.
Sounds like he changed his mind after all.
He did?
I saw a message to Jaakko go by that I interpreted that way. -- Dave Abrahams BoostPro Computing http://www.boostpro.com