Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-01 12:36:54

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/poly_function.hpp
>>>
>>>
> <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