Operator Names

This page has been created on occasion of the extension of Boost.TypeTraits by operator traits to give an overview over existing naming of operators and related operator-fuctors in the standard and boost libraries. The purpose of the page is to collect differences and support convergence.

Column	Comment
op	The operator sign
alt	An alternative tokens, if available
type_traits	boost::type_traits naming as proposed by Frédéric Bron.
MUP	Most Unifying Proposal
std	= : Equal naming in the standard
	=* : Equal naming, new in next standard.
proto	= : Equal naming in boost::proto
	*_p : Partial equality except for a prefix or postfix
operator	Corresponding naming of concepts from boost::operator

The names in column MUP are trying to minimize the differences between names and maximize the naming consistency. The naming from Boost.Proto is found in other boost libraries, e.g. accumulator and phoenix.

op	alt	type_traits	MUP	std	proto	boost::operator	proposed new name
==		equal_to	equal_to	=	=	equality_comparable	can_call_operator_equal_to
!=	not_eq	not_equal_to	not_equal_to	=	=		can_call_operator_not_equal_to
<		less	less	=	=	less_than_comparable	can_call_operator_less
<=		less_equal	less_equal	=	=		can_call_operator_less_equal
>		greater	greater	=	=		can_call_operator_greater
>=		greater_equal	greater_equal	=	=		can_call_operator_greater_equal
+		plus	plus	=	=	addable	can_call_operator_plus
-		minus	minus	=	=	subtractable	can_call_operator_minus
*		multiplies	multiplies	=	=	multipliable	can_call_operator_multiplies
/		divides	divides	=	=	dividable	can_call_operator_divides
%		modulus	modulus	=	=	modable	can_call_operator_modulus
+=		plus_equal	plus_assign		*_assign		can_call_operator_plus_assign
-=		minus_equal	minus_assign		*_assign		can_call_operator_minus_assign
*=		multiplies_equal	multiplies_assign		*_assign		can_call_operator_multiplies_assign
/=		divides_equal	divides_assign		*_assign		can_call_operator_divides_assign
%=		modulus_equal	modulus_assign		*_assign		can_call_operator_modulus_assign
&&	and	logical_and	logical_and	=	=		can_call_operator_logical_and
||	or	logical_or	logical_or	=	=		can_call_operator_logical_or
&	bitand	bit_and	bit_and	=*	bitwise_*	andable	can_call_operator_bitwise_and
|	bitor	bit_or	bit_or	=*	bitwise_*	orable	can_call_operator_bitwise_or
^		bit_xor	bit_xor	=*	bitwise_*	xorable	can_call_operator_bitwise_xor
<<		left_shift	left_shift		shift_left	left_shiftable	can_call_operator_shift_left
>>		right_shift	right_shift		shift_right	right_shiftable	can_call_operator_shift_right
&=	and_eq	bit_and_equal	bit_and_assign		bitwise_and_assign		can_call_operator_bitwise_and_assign
|=	or_eq	bit_or_equal	bit_or_assign		bitwise_or_assign		can_call_operator_bitwise_or_assign
^=	xor_eq	bit_xor_equal	bit_xor_assign		bitwise_xor_assign		can_call_operator_bitwise_xor_assign
<<=		left_shift_equal	left_shift_assign		shift_left_assign		can_call_operator_shift_left_assign
>>=		right_shift_equal	right_shift_assign		shift_right_assign		can_call_operator_shift_right_assign
++		prefix_increment	pre_increment		pre_inc	incrementable	can_call_operator_pre_increment
--		prefix_decrement	pre_decrement		pre_dec	decrementable	can_call_operator_pre_decrement
+		unary_plus	unary_plus		=		can_call_operator_unary_plus
-		unary_minus	negate	negate	negate		can_call_operator_unary_minus
!	not	logical_not	logical_not	=	logical_not		can_call_operator_logical_not
~	compl	complement	complement		complement		can_call_operator_complement
*		dereference	dereference		dereference		can_call_operator_dereference
++		postfix_increment	post_increment		post_inc		can_call_operator_post_increment
--		postfix_decrement	post_decrement		post_dec		can_call_operator_post_decrement

There are some conflicts that have been solved under these rationals.

An name is chosen along these priorities

1. If the name exists in the current c++ standard.
2. If the name exists in the new upcoming c++ standard.
3. Name is not given by 1 or 2 but is used in proto
4. For the remaining conflicts
   1. Does the name follow general boost naming conventions?
   2. Can it be completed to a typical concept name "conceptified". E.g. left_shift -> left_shiftable

o=	op_equal vs. op_assign	proto and other boost::libs agree on op_assign. We can better conceptify to OpAssignable
	bit vs. bitwise	bitwise seems to be more "natural" but some naming in the standard prefers bit_ prefix
<< >>	shift_xxx or xxx_shift	goes to xxx_shift, because we can conceptify to xxx_shiftable more nicely.
++ --	pre/postfix vs. pre/post	goes to pre_in/decrement post_in/decrement. Seems simpler and more natural.

A higher naming consistency could be reached, if the standard was changed for 3 names:

// 20.8.7, bitwise operations:
template <class T> struct bit_and;
template <class T> struct bit_or;
template <class T> struct bit_xor;

In this case all the bit prefixes could be replaced by bitwise, so it would be consistent with all proto names referring to bitwise operations. Note that "20.8.7, bitwise operations" are all part of the new upcoming standard and could still be changed.

Proposed Names For Final Version

operator	trait name
+	can_add<T1, T2>
-	can_subtract<T1, T2>
*	can_multiply<T1, T2>
/	can_divide<T1, T2>
%	can_modulate<T1, T2>
+=	can_add_assign<T1, T2>
-=	can_subtract_assign<T1, T2>
*=	can_multiply_assign<T1, T2>
/=	can_divide_assign<T1, T2>
%=	can_modulate_assign<T1, T2>
&	can_bitwise_and<T1, T2>
|	can_bitwise_or<T1, T2>
^	can_bitwise_xor<T1, T2>
&=	can_bitwise_and_assign<T1, T2>
|=	can_bitwise_or_assign<T1, T2>
^=	can_bitwise_xor_assign<T1, T2>
<<	can_left_shift<T1, T2>
>>	can_right_shift<T1, T2>
<<=	can_left_shift_assign<T1, T2>
>>=	can_right_shift_assign<T1, T2>
==	can_call_equal_to<T1, T2>
!=	can_call_not_equal_to<T1, T2>
<	can_call_less<T1, T2>
<=	can_call_less_equal<T1, T2>
>	can_call_greater<T1, T2>
>=	can_call_greater_equal<T1, T2>
&&	can_logical_and<T1, T2>
||	can_logical_or<T1, T2>
!	can_logical_not<T>
+	can_unary_plus<T>
-	can_negate<T>
~	can_complement<T>
*	can_dereference<T>
++	can_pre_increase<T>
--	can_pre_decrease<T>
++	can_post_increase<T>
--	can_post_decrease<T>