Re: [boost] [parameter] named template parameters

Subject: Re: [boost] [parameter] named template parameters
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-11-03 14:27:10

On Thu, Nov 3, 2011 at 11:05 AM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:

> On Wed, Nov 2, 2011 at 6:46 PM, Jeffrey Lee Hellrung, Jr.
> <jeffrey.hellrung_at_[hidden]> wrote:
> > On Wed, Nov 2, 2011 at 2:00 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]
> >wrote:
>
[...]

> >> A couple more things:
> >>
> >> 1) I thing that BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) macro
> >> should define a symbol _ClassType to be used for the named parameter
> >> so to be consistent with the BOOST_PARAMETER_NAME(x) which defined _x
> >> to be used for the named function parameter. However, ClassType is
> >> defined without the leading _. What is the reason for this asymmetry?
> >>
> >
> > The fact that each keyword is used in different contexts is enough
> > justification for me to explain the asymmetry.
> >
> > I gathered the leading underscored prepended to function parameter
> keywords
> > was motivated by a desire to prevent shadowing bugs (as per the rationale
> > given in the documentation, if I remember correctly).  No such problem
> > arises with template parameter keywords, so the only justification I can
> > think of to prepend template parameter keywords with an underscore is
> > because that's what's done with function parameter keywords, which seems
> > kind of weak.
>
> Yes but these all sound like implementation reasons to me. If the
> parameter name keywords need the leading _ for functions, as a library
> users I'd expect the template parameters to follow the same
> convention. Why should a user expect template parameter name keywords
> to follow a different convention than function parameter name
> keywords?
>

Well, they have different syntax as well, i.e., "_keyword = value" vs
"keyword< value >" (I guess that's also technically an implementation
detail...).  My point being, function parameter keyword syntax and template
parameter keyword syntax differ, so I don't think it's too onerous for the
naming conventions to differ as well.  But I see your point, and it
probably could've easily gone the other way; honestly, I don't think the
argument either way is particularly strong, and by now I'm used to the
differing naming convention, so *I* am willing to accept that "this is just
the way it is".  That's not really suppose to convince *you*, though :)

- Jeff