Eric Niebler wrote:
David Abrahams wrote:
Eric Niebler wrote:
Agreed. I've written my own Egg-like function object adaptor to do the "right thing" with lvalues and rvalues. It lives here:
http://svn.boost.org/trac/boost/browser/branches/proto/v4/boost/proto/detail...
<snip>
It forwards reference-wrapped arguments to the monomorphic implementation as lvalues, and all others as rvalues.
Very cool. I don't suppose it's possible to forward lvalues and const rvalues as lvalues, and mutable rvalues as rvalues? I haven't thought of a way, but that would be as close to "perfect" as we might expect to get in C++0x and it would be close enough for me :-)
We would need 2^N overloads,
That's OK for small N
and it would be unsound because it would incorrectly forward const rvalues as lvalues.
Can you show me an example of a "sound" function that treats a const rvalue differently from an lvalue, please?
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.
<snip>
I think a wrapper like the one above that makes it easy to author polymorphic function objects that consistently handle lvalues and rvalues is a good first step.
Great! Problem: it's not publicly available in Boost (yet)/
A simple, light-weight utility such as this would be very helpful, and probably not too hard to get through on a fast-track review, if we could just agree on semantics.
Or we could stick it in utility without review, since I'm a maintainer of that "library" (gotta love these loopholes!)
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. -- Dave Abrahams BoostPro Computing http://www.boostpro.com