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-18 07:58:51

On 11/18/2010 3:16 AM, Frédéric Bron wrote:
>>> I really don't mind if it gets spelled with namespaces instead of
>>> underscores, but a using declaration is not a motivation for it.
>>
>> OK. But I prefer namespaces rather than decorating names with some common
>> 'prefix' to show commonality. I personally believe as an end-user that there
>> is the tendency to pile too much directly into the boost namespace.
>
> Using namespaces, it would become:
>    namespace boost { namespace operators {
>      has_equal_to
>      has_not_equal_to
>      has_greater
>      has_greater_equal
>      has_less
>      has_less_equal
>      has_plus
>      has_minus
>      ...
> }}
>
> There would be a small inconsistency because for example we have
> boost::algorithm:: (singular) but boost::operators:: (plural) but we
> clear cannot use boost::operator::.

I would not worry about the inconsistency.

>
> For such a decision, that is if we go for has_operator_xxx or
> operators::has_xxx, what is the practice to decide what we accept?
> Obviously it would be difficult to have everybody satisfied with either method.
> I do not want to switch to namespace if we are not sure to go for it.
>
> Same question for has_new_operator vs has_operator_new vs operators::has_new

I think if we go for a boost::operators namespace we should not worry 
about tacking the 'operator_' onto the individual names at all, as in 
your brief enumeration above.

OTOH if, like the rest of type_traits, it all goes in the boost 
namespace, my preference is to use 'has_operator_' as the prefix to all 
of the operator functionality.

John Maddock, whose the type_traits developer, may also have a 
preference here.

I personally would not spend too much time thrashing about it.

But it is really your call ultimately.