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.