wiki:GuideLines/Naming/OperatorTraitNames

Version 5 (modified by Joachim Faulhaber, 11 years ago) ( diff )

--

Introduction

This page gives different proposals to name the traits that answer the following questions:

  • if "@" is a binary operator, can you write somewhere in your code "lhs @ rhs",
  • if "@" is a prefix unary operator, can you write somewhere in your code "@ rhs",
  • if "@" is a postfix unary operator, can you write somewhere in your code "lhs @",

lhs and rhs being of any types provided as template parameters to the trait. Optionnaly, the traits can also answer if the operator return type is convertible to some type.

In particular, the traits do not say if the corresponding operators are members of a given class but only if the operators can be called with given arguments. If the answer is yes, the operators can be member functions or a free functions or a built-in operators.

Proposals

operator A: review B C D
+ has_operator_plus can_call_addition can_add has_plus
- has_operator_minus can_call_subtraction can_subtract has_minus
* has_operator_multiplies can_call_multiplication can_multiply has_multiplies
/ has_operator_divides can_call_division can_divide has_divides
% has_operator_modulus can_call_modulus can_call_modulus has_modulus
+= has_operator_plus_equal can_call_addition_assignment can_add_assign has_plus_assign
-= has_operator_minus_equal can_call_subtraction_assignment can_subtract_assign has_minus_assign
*= has_operator_multiplies_equal can_call_multiplication_assignment can_multiply_assign has_multiplies_assign
/= has_operator_divides_equal can_call_division_assignment can_divide_assign has_divides_assign
%= has_operator_modulus_equal can_call_modulus_assignment can_call_modulus_assign has_modulus_assign
& has_operator_bit_and can_call_bitwise_and can_bitwise_and has_bit_and
| has_operator_bit_or can_call_bitwise_or can_bitwise_or has_bit_or
^ has_operator_bit_xor can_call_bitwise_xor can_bitwise_xor has_bit_xor
&= has_operator_bit_and_equal can_call_bitwise_and_assignment can_bitwise_and_assign has_bit_and_assign
|= has_operator_bit_or_equal can_call_bitwise_or_assignment can_bitwise_or_assign has_bit_or_assign
^= has_operator_bit_xor_equal can_call_bitwise_xor_assignment can_bitwise_xor_assign has_bit_xor_assign
<< has_operator_left_shift can_call_shift_left can_left_shift has_left_shift
>> has_operator_right_shift can_call_shift_right can_right_shift has_right_shift
<<=has_operator_left_shift_equal can_call_shift_left_assignment can_left_shift_assign has_left_shift_assign
>>=has_operator_right_shift_equal can_call_shift_right_assignment can_right_shift_assign has_right_shift_assign
== has_operator_equal_to can_call_equal can_equal_compare has_equal_to
!= has_operator_not_equal_to can_call_not_equal can_not_equal_compare has_not_equal_to
< has_operator_less can_call_less can_less_compare has_less
<= has_operator_less_equal can_call_less_equal can_less_equal_compare has_less_equal
> has_operator_greater can_call_greater can_greater_compare has_greater
>= has_operator_greater_equal can_call_greater_equal can_greater_equal_compare has_greater_equal
&& has_operator_logical_and can_call_and can_logical_and has_logical_and
|| has_operator_logical_or can_call_or can_logical_or has_logical_or
! has_operator_logical_not can_call_not can_logical_not has_logical_not
+ has_operator_unary_plus can_call_unary_plus can_positivate has_unary_plus
- has_operator_unary_minus can_call_unary_minus can_negate has_negate
~ has_operator_complement can_call_complement can_complement has_complement
* has_operator_dereference can_call_dereference can_dereference has_dereference
++ has_operator_prefix_increment can_call_pre_increment can_pre_increase has_pre_increment
-- has_operator_prefix_decrement can_call_pre_decrement can_pre_decrease has_pre_decrement
++ has_operator_postfix_increment can_call_post_increment can_post_increase has_post_increment
-- has_operator_postfix_decrement can_call_post_decrement can_post_decrease has_post_decrement

Comments during the official review

date who comment
14/03/2011 vijayan12 replace _equal by _assign
14/03/2011 vicente.bote replace _equal by _assign
14/03/2011 vicente.bote shift -> bit_left/right_shift
14/03/2011 vicente.bote complement -> bit_not
14/03/2011 vicente.bote prefix_ -> pre_, postfix_ -> post_
15/03/2011 vicente.bote &,|,,~,<<,>> are bit operators and all should be named following the same schema.
15/03/2011 thom.helle 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.
15/03/2011 jhellrun I prefer op_equal as well, but it's not a strong preference.
15/03/2011 jhellrun I, too, prefer shift_left and shift_right, given their ubiquity related to std::iostream.
15/03/2011 pbristo There would seem to me to be a very strong case for having the same names as in Boost.Proto and Boost.Operator.
15/03/2011 vicente.bote I have a little problem with the has_operator_ prefix on the name of the traits. The traits is not checking the class parameter(s) has/have an operator, but that the application of the operator to this/these types is syntactically correct. E.g. has_operator_plus&lt;int, double&gt;::value neither int nor double have an operator+. applicable_operator_plus&lt;int, double&gt;::value or can_apply_operator_plus could be an option.
16/03/2011 eldiene has_ is fine
16/03/2011 robert.stewar replace _equal by _assign
16/03/2011 robert.stewar plus_equal -> add_assign
16/03/2011 robert.stewar multiplies -> multiply, divides -> divide
16/03/2011 robert.stewar bit -> bitwise
16/03/2011 robert.stewar prefer direction followed by shift (right/left_shift) than shift followed by direction
16/03/2011 robert.stewar I generally like the names from Proto. Consistency would be nice, but consider the names as they are likely to be standardized. Better to get the names "right" now. For example, I think "postfix_increment" is a likely name for standardization, while "post_inc" is not.
16/03/2011 joel.falco add typedefs for proto consistency
16/03/2011 vicente.bote do not mix operators and concepts (equality_comparable, addable, less_than_comparable) which are adjectives
16/03/2011 vicente.bote std::ratio uses add, subtract, multiply and divide, this corresponds to verbs not to nouns and have a semantic associated. Boost.MPL has also some names for arithmetic operators. It uses plus, minus, times and divides. I think that that the names we are looking for should be names.
16/03/2011 vicente.bote bit -> bitwise
16/03/2011 vicente.bote prefer direction followed by shift (right/left_shift) than shift followed by direction
16/03/2011 vicente.bote used in standard: prefix/postfix increment/decrement, pre/post increment/decrement
17/03/2011 boost.rege names proposed are consistent
18/03/2011 afojg has_operator_xxx is imprecise and should be operator_xxx_applicable_to or operator_xxx_callable_on instead?
18/03/2011 eldiene IMO nobody is going to be comfortable with 'operator_xxx_callable_on' as opposed to 'has_operator_xxx'.
18/03/2011 jeffrey.hellrun prefers is_xxxable to has_operator_
18/03/2011 jeffrey.hellrun prefers plus, minus to add, substract
18/03/2011 jeffrey.hellrun prefers plus_equal to plus_assign
18/03/2011 jeffrey.hellrun prefers post/pre_increment/decrement to postfix/prefix_increment/decrement
18/03/2011 jeffrey.hellrun prefers bit_ to bitwise_
18/03/2011 afojg has_operator_xxx seems to be imprecise and misleading
18/03/2011 afojg has_operator_xxx introduces a redundant prefix 'has_operator'
18/03/2011 afojg plus_assign_callable or plus_assignable
18/03/2011 boost.rege plus_assignable -> is_plus_assignable
18/03/2011 robert.stewar plus_assignable -> is_add_assignable
18/03/2011 robert.stewar can_assign_sum/difference/product/quotient
18/03/2011 robert.stewar can_add_and_assign/subtract_and_assign/multiply_and_assign/divide_and_assign
18/03/2011 vicente.bote can_add/multiply/left_shift/post_increase/add_assign/subtract_assign/multiply_assign/divide_assign
19/03/2011 afojg The name has_operator_xxx misleads to the assumption, that the signature of an operator can be checked directly. At least naive users (like me;) may fall into this trap.
19/03/2011 afojg remove operator_
19/03/2011 afojg (1) Consistency with general math and scientific knowledge (2) Consistency with standards (2.1) Consistency with c++ standards (2.2) Consistency with boost (2.3) Consistency with other standards, if they exist (3) Conciseness (3.1) Precise and descriptive (3.2) Adequate level of abstraction (3.3) Reduced for unnecessary redundancies (3.4) Relatedness to other names with similar meanings.
19/03/2011 afojg +: cross, -: dash, *: star, /: slash
19/03/2011 spillne is_callable<plus, LeftOperandType, RightOperandType>, result_of<plus, LeftOperandType, RightOperandType, ReturnType>, retval_convertible_to<plus, LeftOperand, RightOperandType, EquivalentReturnType>, is_prefix_callable<plusplus, OperandType>, is_postfix_callable<plusplus, OperandType>
21/03/2011 afojg https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
24/03/2011 afojg + cross, addition, set union, concatenation, ...
24/03/2011 afojg - dash, subtraction, set difference, deletion ...
24/03/2011 afojg * star, multiplication, intersection, Cartesian product ...
24/03/2011 afojg / slash, division, factorization, ...
28/03/2011 dherrin has_op_xxx
Note: See TracWiki for help on using the wiki.