Re: [boost] review request: addition to type_traits library ofhas_operator_xxx

Subject: Re: [boost] review request: addition to type_traits library ofhas_operator_xxx
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-11-17 17:23:50

On 11/17/2010 3:48 PM, Stewart, Robert wrote:
> Frédéric Bron wrote:
>>
>>> Those names are not consistent with
>>> boost::has_new_operator.  That is, you need to rename them
>>> like the following for consistency:
>>>
>>>    s/has_operator_\(.+\)/has_\1_operator/
>>>
>>> The result won't be perfect.  For example,
>>> "has_operator_divides" should be renamed "has_division_operator."
>>>
>>> Renaming "has_new_operator" seems more appropriate,
>>> however.  "has_operator_new" puts "operator" and "new" in the
>>> right order as the query is for operator new, not the new operator.
>>>
>>> The same discussion applies to the other traits.
>>
>> The question of naming has already been discussed here :
>> http://thread.gmane.org/gmane.comp.lib.boost.devel/194625
>
> There wasn't much discussion.  You asked about "has_operator_less_than" versus "has_less_than_operator" and I suggested that the former is more consistent with C++ syntax, but that deviates from boost::has_new_operator.
>
>> At that time, we preferred has_operator_xxx to has_xxx_operator.
>
> I still think its better.

I agree also. Having all the operator traits begin with 'has_operator_' 
makes their use easier to remember.

Alternatively I could even see putting all the operator traits in their 
own namespace of 'boost::operators', dropping the 'operator_' in their 
name, and allowing the end-user to surface them to just the 'boost' 
namespace via a using declaration as they like. But then again, I am a 
very strong supporter of namespaces and allowing the end-user to expose 
what they want from namespaces via 'using'.