On Mon, Jul 23, 2012 at 3:30 PM, Steven Watanabe <watanabesj@gmail.com> 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/...
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