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

Subject: Re: [boost] [bind][phoenix] unified placeholders, yea or nay?
From: Joel de Guzman (joel_at_[hidden])
Date: 2012-05-29 06:16:35

On 5/29/2012 3:35 PM, Thomas Heller wrote:
> On 05/28/2012 01:22 AM, 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.
>>
> FWIW, phoenix should be able to use bind placeholder. In fact, phoenix can use any
> placeholder that specializes boost::is_placeholder. Couldn't we work off of that?
> For example, detect in the phoenix code wether the bind header has been included before?
> Issue a warning? error?

ADL won't pickup phx functions and operators if the placeholders
are in a different namespace unless they are tinged somehow with
some proto/phx. _1 + _2 will not work if _1 and _2 are both totally
oblivious of proto/phx. boost::is_placeholder is not enough.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com