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