Re: [boost] [bind][phoenix] unified placeholders, yea or nay?

Subject: Re: [boost] [bind][phoenix] unified placeholders, yea or nay?
From: Eric Niebler (eric_at_[hidden])
Date: 2012-05-28 23:33:55

On 5/28/2012 7:56 PM, Steven Watanabe wrote:
> AMDG
> 
> On 05/27/2012 04:22 PM, Eric Niebler wrote:
>> I'm considering taking on as a side project the unification of the bind
>> and phoenix placeholders, a perennial source of confusion and annoyance.
>> I hesitate before beginning because it necessarily introduces some
>> complexity into boost.bind, a very small, simple, and light-weight
>> library. In particular, the unification would:
>>
>> 1) Cause boost.bind to depend on boost.proto. (I would do what I could
>> to keep that dependency as slight as possible.)
>> 2) Could not be supported on all platforms; e.g. not on borland or (gcc
>> < 4) where the placeholders are actually static inline functions(!).
>> (Peter, is this an ODR thing?)
>> 3) Would introduce Phoenix behaviors into Bind, insofar as _1 is a
>> lambda such that _1(42) evaluates to 42.
>>
>> At this point, it's not obvious to me that the benefits outweigh the
>> costs. Opinions? Peter, I'd especially like to hear your thoughts.
>>
> 
> I think this is hard to do without breaking user code.
> Consider:
> 
> using ::_1;
> boost::function<int(int)> f1;
> bind(f1, _1); // boost::bind
> ...
> using boost::phoenix::placeholders::_1;
> bind(std::plus<int>(), _1, _1); // boost::phoenix::bind
> 
> Unifying ::_1 and boost::phoenix::placeholders::_1
> has to break one of these unless boost::bind
> is also the same as boost::phoenix::bind.

Your point is about ADL not finding correct bind function, right? Yes,
that's a problem I hadn't considered. Is it serious, in your opinion? I
haven't formed an opinion yet.

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