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-27 19:47:37

On 5/27/2012 4:35 PM, lcaminiti wrote:
> 
> Eric Niebler-3 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.
>>
> 
> Bind should really not define _1, ... into the unamed namespace (IMO, this
> should be fixed in future Boost releases even if it will of course brake
> backward compatibility and existing code -- users can easily fix their
> existing code with using namespace boost::bind...).

I am not proposing to change that.

> A part from that, why are Bind's placeholder confusing?

They are not confusing in and of themselves. They are confusing when
users include both phoenix and bind (perhaps indirectly), and find that
references to _1 are ambiguous and need to be qualified.

>> 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.
>>
> 
> Would it also complicate Bind compile-time errors?

I don't believe it should.

>> 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.
>>
> 
> What are the benefits of the unification?

No more ambiguity errors. Phoenix and bind would share placeholders.

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