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

Choose between A, B and C.

operator	A	B	C	standard keyword	standard <functional>	boost Proto	boost Operators
+	can_call_addition	has_plus	has_plus	0	plus	plus	0
-	can_call_subtraction	has_minus	has_minus	0	minus	minus	0
*	can_call_multiplication	has_multiplies	has_multiplies	0	multiplies	multiplies	0
/	can_call_division	has_divides	has_divides	0	divides	divides	0
%	can_call_modulus	has_modulus	has_modulus	0	modulus	modulus	0
+=	can_call_addition_assignment	has_plus_equal	has_plus_assign	0	0	plus_assign	addable
-=	can_call_subtraction_assignment	has_minus_equal	has_minus_assign	0	0	minus_assign	substractable
*=	can_call_multiplication_assignment	has_multiplies_equal	has_multiplies_assign	0	0	multiplies_assign	multipliable
/=	can_call_division_assignment	has_divides_equal	has_divides_assign	0	0	divides_assign	dividable
%=	can_call_modulus_assignment	has_modulus_equal	has_modulus_assign	0	0	modulus_assign	modable
&	can_call_bitwise_and	has_bit_and	has_bit_and	bitand	bit_and	bitwise_and	0
|	can_call_bitwise_or	has_bit_or	has_bit_or	bitor	bit_or	bitwise_or	0
^	can_call_bitwise_xor	has_bit_xor	has_bit_xor	xor	bit_xor	bitwise_xor	0
&=	can_call_bitwise_and_assignment	has_bit_and_equal	has_bit_and_assign	and_eq	0	bitwise_and_assign	andable
|=	can_call_bitwise_or_assignment	has_bit_or_equal	has_bit_or_assign	or_eq	0	bitwise_or_assign	orable
^=	can_call_bitwise_xor_assignment	has_bit_xor_equal	has_bit_xor_assign	xor_eq	0	bitwise_xor_assign	xorable
<<	can_call_shift_left	has_left_shift	has_left_shift	0	0	shift_left	0
>>	can_call_shift_right	has_right_shift	has_right_shift	0	0	shift_right	0
<<=	can_call_shift_left_assignment	has_left_shift_equal	has_left_shift_assign	0	0	shift_left_assign	left_shiftable
>>=	can_call_shift_right_assignment	has_right_shift_equal	has_right_shift_assign	0	0	shift_right_assign	right_shiftable
==	can_call_equal	has_equal_to	has_equal_to	0	equal_to	equal_to	equality_comparable
!=	can_call_not_equal	has_not_equal_to	has_not_equal_to	not_eq	not_equal_to	not_equal_to	0
<	can_call_less	has_less	has_less	0	less	less	less_than_comparable
<=	can_call_less_equal	has_less_equal	has_less_equal	0	less_equal	less_equal	0
>	can_call_greater	has_greater	has_greater	0	greater	greater	0
>=	can_call_greater_equal	has_greater_equal	has_greater_equal	0	greater_equal	greater_equal	0
&&	can_call_and	has_logical_and	has_logical_and	and	logical_and	logical_and	0
||	can_call_or	has_logical_or	has_logical_or	or	logical_or	logical_or	0
!	can_call_not	has_logical_not	has_logical_not	not	logical_not	logical_not	0
+	can_call_unary_plus	has_unary_plus	has_unary_plus	0	0	unary_plus	0
-	can_call_unary_minus	has_unary_minus	has_negate	0	negate	negate	0
~	can_call_complement	has_complement	has_complement	compl	0	complement	0
*	can_call_dereference	has_dereference	has_dereference	0	0	dereference	0
++	can_call_pre_increment	has_pre_increment	has_pre_increment	0	0	pre_inc	incrementable
--	can_call_pre_decrement	has_pre_decrement	has_pre_decrement	0	0	pre_dec	decrementable
++	can_call_post_increment	has_post_increment	has_post_increment	0	0	post_inc	0
--	can_call_post_decrement	has_post_decrement	has_post_decrement	0	0	post_dec	0

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