2011/4/28 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
I chose "has_" for the same reason: Consistency within boost, because the type traits library uses has_ in similar instances. The argument, that this is an imprecise naming because for free standing operators ownership can not be determined is unimportant because we may conceive the complete type signature as the type that "owns" the operator:
A x B -> B has_plus
Thinking of A and B as a universe that may or may not include a particular operator, whether through a member function or not, is a reasonable way to interpret things. On that basis, I now find "has_" acceptable.
the beauty of generic designs based on concepts is, that it gently dissolves object oriented views of membership anyway. So we can think of a triple of types (A1, A2, R) that "has" an implementation for an operator @ which means that it is applicable, can be called on or supports those type arguments. has_ reads well under this "modern" interpretation. We can prefer it for consistency sake concerning other uses of has_ in Boost.TypeTraits and because
it has simplicity and brevity; as Jeff wrote
Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de