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
+	has_operator_plus	can_call_addition
-	has_operator_minus	can_call_subtraction
*	has_operator_multiplies	can_call_multiplication
/	has_operator_divides	can_call_division
%	has_operator_modulus	can_call_modulus
+=	has_operator_plus_equal	can_call_addition_assignment
-=	has_operator_minus_equal	can_call_subtraction_assignment
*=	has_operator_multiplies_equal	can_call_multiplication_assignment
/=	has_operator_divides_equal	can_call_division_assignment
%=	has_operator_modulus_equal	can_call_modulus_assignment
&	has_operator_bit_and	can_call_bitwise_and
|	has_operator_bit_or	can_call_bitwise_or
^	has_operator_bit_xor	can_call_bitwise_xor
&=	has_operator_bit_and_equal	can_call_bitwise_and_assignment
|=	has_operator_bit_or_equal	can_call_bitwise_or_assignment
^=	has_operator_bit_xor_equal	can_call_bitwise_xor_assignment
<<	has_operator_left_shift	can_call_shift_left
>>	has_operator_right_shift	can_call_shift_right
<<=	has_operator_left_shift_equal	can_call_shift_left_assignment
>>=	has_operator_right_shift_equal	can_call_shift_right_assignment
==	has_operator_equal_to	can_call_equal
!=	has_operator_not_equal_to	can_call_not_equal
<	has_operator_less	can_call_less
<=	has_operator_less_equal	can_call_less_equal
>	has_operator_greater	can_call_greater
>=	has_operator_greater_equal	can_call_greater_equal
&&	has_operator_logical_and	can_call_and
||	has_operator_logical_or	can_call_or
!	has_operator_logical_not	can_call_not
+	has_operator_unary_plus	can_call_unary_plus
-	has_operator_unary_minus	can_call_unary_minus
~	has_operator_complement	can_call_complement
*	has_operator_dereference	can_call_dereference
++	has_operator_prefix_increment	can_call_pre_increment
--	has_operator_prefix_decrement	can_call_pre_decrement
++	has_operator_postfix_increment	can_call_post_increment
--	has_operator_postfix_decrement	can_call_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
29/03/2011	afojg	is_xxx_callabe
29/03/2011	afojg	can_call_equal_to