Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron

Subject: Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-03-15 07:22:37

On Tue, Mar 15, 2011 at 12:04 PM, Stewart, Robert
<Robert.Stewart_at_[hidden]> wrote:
> Vicente Botet wrote:
>> Frédéric Bron wrote:
>> >
>> >> Last I agree that the use of equal should be replaced by
>> >> assign when assignment is intended
>> >> += has_operator_plus_equal -> has_operator_plus_assign
>> >> -= has_operator_minus_equal -> has_operator_minus_assign
>> >
>> > Why? is it to avoid confusion with "equal to"?
>> > I like plus_equal because plus is a sign and equal is also
>> > a sign. So I think it is easier to remember.
>>
>> No, it is because the intended behavior on the builtin types
>> is to make an assignment. Remember in C++ user defined types
>> should follow the builtin semantics when possible.
>
> The "when possible" is a hint that such semantics are not always followed.  There are legitimate cases in which a type has no relationship to built-in types, yet overloads operators.  In such cases, the built-in semantics don't guide the naming of the operators.  For example, the use of the left and right shift operators which, by the way, I never call "bit shift left" and "bit shift right" but just "left shift" and "right shift," are called the insertion and extraction operators in IOStreams.  That augurs for naming the traits for the symbols rather than the semantics as Frédéric has done in this case so as to be more general.
>
> The question is whether all of the type traits names consistently follow the symbolic approach. Â If some are symbolic and others semantic, confusion is more likely.

WRT naming i think we should strive for consistent naming in overall
boost, not just the type_traits library. Proto, for example, names the
operators as well, as does Boost.Operator.
FWIW both libraries agree on left_shift/right_shift.

Please take that into consideration.