1 Jul
2008
1 Jul
'08
4:01 p.m.
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