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.