Re: [boost] [TypeErasure]

Subject: Re: [boost] [TypeErasure]
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-07-23 15:42:28

On Mon, Jul 23, 2012 at 3:30 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> On 07/23/2012 11:17 AM, Markus Werle wrote:
>> Steven Watanabe wrote:
>>> On 07/22/2012 07:21 AM, Markus Werle wrote:
>>>>
>>>> I have one question: proto and spirit use _1, _2, etc.
>>>> TypeErasure uses _a, _b, _c ...
>>>> What was your reason to introduce yet another placeholder set?
>>>
>> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/design.html#boost_typeerasure.design.placeholder
>>
>> I disagree with this decision. You write:
>>
>>> An earlier version of the library used the names _1, _2, etc.
>>> instead of _a, _b, etc. This caused a certain amount of confusion
>>> because the numbered placeholders are already used by several
>>> other libraries including Boost/Std Bind, Boost.Phoenix, and Boost.MPL.
>>
>> IMHO the introduction of another set of placeholders is more confusing.
>> If we are to discriminate here, we can do it via namespaces - and of course
>> one day it is std::_1 for all of us.
>>
>> Just because your library is the first to use _a, _b, _c
>
> It isn't.  Boost.Phoenix uses _a, _b, etc for local
> variables.
>
>> what does that mean
>> for future (boost) libraries that use some kind of placeholders?
>> Do they have to use _aa, _bb, etc.?
>> To me placeholders are such a natural concept I do not care about having
>> some kind of "deja vu" here. To the contrary: The meaning (placeholder) is
>> identical so we should use identical names.
>>
>
> It isn't exactly identical.  The names _1, _2
> carry extra meaning about how they are substituted
> which doesn't make sense for my library.
>
>>> I eventually decided that since the placeholders represented named
>>> parameters instead of positional parameters, letters were more
>>> appropriate than numbers.

I've asked the same question "why _a, _b, etc instead of _1, _2, etc"
a while back. Steven replied, it's because _a, _b, etc are
placeholders for named parameters and not for positional parameters
(I'm not sure if this is explicitly stated in the documentation). That
makes sense to me -- _1, _2, etc are placeholders for positional
parameters in all other libs mpl, bind, phoenix, etc so they should
not be used for named parameters.

>> Indeed the naming is arbitrary. Starting from the same observation (_1 is
>> already available in boost::*) I draw the opposite conclusion:
>> Use these names for the sake of symmetry and hope for convergence of
>> concepts over the years.
>>
>> @Review Master: Should I miss the end date for reviews, take this as my mini
>> subset of a review: I'd prefer _1, _2 instead of _a, _b.
>>
>
> You are of course free to disagree with
> my decision, but I'm not going to change it.

--Lorenzo