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

From: Eric Niebler (eric_at_[hidden])
Date: 2008-07-01 12:01:33

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, and it would be unsound because it would
incorrectly forward const rvalues as lvalues. 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.

<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.

>> <snip>
>>>>> lambda/phoenix/bind
>>> * Incompatible placeholders * Been waiting for the lambda/phoenix
>>> merger forever * Lambda has lots of limitations and gotchas that
>>> we can improve on now * Phoenix 2.0 not in Boost
>> I've already taken the first and (IMO) most important step here by 
>> porting both Lambda and Phoenix to Proto. My opinion on the
>> unification of Lambda and Phoenix is that it shouldn't happen.
>> There are too many subtle differences in semantics. Rather, Lambda
>> should be retired and Phoenix should be promoted (after being
>> reviewed, etc.).
> 
> That's OK too, although Joel still seems to be intent on an eventual
> merger.

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.

>> The placeholders should be Proto terminals shared across Phoenix,
>> Bind, Xpressive, Spirit and any other library that needs numbered 
>> placeholders.
> 
> 'xcept MPL

'course.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com