Also, while we're on the topic of what *I* prefer: I still prefer "has_xxx". To me, it has an implicit association (to me, anyway) to the names of trait predicates; it has simplicity and brevity; and it has existing use in Boost.TypeTraits. I can sympathize with arguments against "has_xxx" / for "can_call_xxx", I just never thought they were convincing enough :/
The decision is ultimately Mr. Bron's, though, and I'm sure he's doing his best to try to please everyone :)
There are two things: the names and the prefix. And they are related. About the prefix: I don't like can_call_. It is novel as Joachim says, and AFAIK not widely used, and looking a bit awkward (in my opinion). In such cases I normally use "supports", so: supports_addition, supports_equal, supports_not. It is not shorter (neither longer) but reads more smoothly. Next step: inserting the "operator_ " is even more clear. So supports_operator_not is more convenient: longer, but more clear. Next step: then "has_" is more convenient, because complying to existing practice. So: "has_operator_not". Perfect. But "has_operator_addition" is not perfect, is awkard. This shows the problem, the prefix and the name are related: it should then be has_operator_plus... It is not the "operator_addition" it supports, it is the "operator_plus" it supports (doing an addition). About the names (and the names only), I agree with Joachim, conform to existing practice, don't invent the wheel again. Proto has all of the presented list, but using other terms. So why type types extensions would present another compilation? Why should it be proto::plus and can_call_addition? proto::equal_to and can_call_equal? proto::shift_left and can_call_left_shift Very confusing. OK, it is not consistent among Boost libraries (which is bad), but then take the library having the complete list (which is probably Proto). So I prefer what (if I'm right) has been proposed before: proto::plus and has_operator_plus proto::equal_to and has_operator_equal_to proto::shift_left and has_operator_shift_left all exactly like proto, but having the "has_operator_" prefix. I cannot remember what was the objection to has_, but then supports_ would be the alternative of my choice. The only exception would be, for logical reasons, and_ and or_ and not_, so proto::and_ and has_operator_and proto::or_ and has_operator_or Regards, Barend