Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision

Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Barend Gehrels (barend_at_[hidden])
Date: 2011-04-21 15:09:50

>
> 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