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

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-01 11:27:15

Eric Niebler wrote:
> David Abrahams wrote:
>>>> Here are the parts and topics that I see as being in the category:
>>>>
>>>> result_of
>>
>> * Too hard to define result<> templates for polymorphic function objects.
> 
> 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
>
> It is a polymorphic function object wrapper around a template that
> generates monomorphic function objects. (So it's analagous to
> mpl::quoteN, which turns a metafunction into a metafunction class.) 

The analogy doesn't seem quite right, but OK

> 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 :-)

> TODO: replace all Proto's function objects with this wrapper to enforce
> consistent behavior. All function objects across Boost that need to make
> rvalue/lvalue distinctions would need to be examined for consistency in
> this regard. Joel, I'm looking in Fusion's general direction.

Yep.  It's a big coordination job.

>> * A whole spate of questions that came up in
>> http://article.gmane.org/gmane.comp.lib.boost.devel/173370 were not
>> answered with a page of documentation, utility library, or other
>> facility.  I still don't know what the upshot was
> 
> I still don't know either, sadly, but 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)/

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

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

'xcept MPL