Re: [boost] [bind][tr1] patch for more compliant placeholders

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-04-28 12:04:46

On 4/27/07, Peter Dimov <pdimov_at_[hidden]> wrote:
> Eric Niebler wrote:
> > Peter Dimov wrote:
> >> Eric Niebler wrote:
> >>
> >>> Although I don't know all the details of bind and lambda, I had
> >>> hoped that _1 and _2 would be abstract proto entities, such that
> >>>
> >>>    _1 == _2
> >>>
> >>> creates an expression template like:
> >>>
> >>>    equal< terminal< arg<1> >, terminal< arg<2> > >
> >>>
> >>> which is a generic, abstract representation of an equals expression
> >>> with two placeholders. Can't bind and lambda both be implemented to
> >>> recognize such a type and do the appropriate thing with it?
> >>
> >> Possibly, if they are made to honor is_bind_expression
> >> specializations and result_of, if is_bind_expression reports true
> >> for the above type, if the above is a function object that actually
> >> returns x == y, and if result_of works for it.
> >
> > Yes, that can all be made to work without much difficulty.
>
> The part about boost::bind using is_bind_expression and result_of cannot,
> not without major surgery and possibly compromising portability.
>
> Sometimes I get excited about the new C++0x features and tell myself, why
> not rewrite boost::bind to take advantage of them? Then it occurs to me that
> C++0x has a std::bind built-in. :-) (Happened twice so far.)

Actually, I think that's a great idea down the road. Boost.Bind can
still be useful even after everyone gets std::bind at no additional
cost with their compiler (though that might not happen 'til 2010 or
so). If the current TR1 bind implementation were moved to Boost.TR1
then Boost.Bind could improve on the standard.

One area where it could do better is in adaptability for call
wrappers. In TR1 3.3/3 call wrappers with weak result types (the
wrappers that bind must generate when the Result template parameter is
not explicitly used) are required be un-adaptable (no result_type
member) if the bound function object has no result_type member. It
could do better if it provided a result<> member that used result_of.
To go one step further, if Boost provided a result_of implementation
using decltype in addition to a TR1 compliant result_of, Boost.Bind
could support perfect, generic, non-intrusive return type deduction.

Daniel