Stewart, Robert wrote:
John Maddock wrote:
I'd prefer is_plus_assignable if we go that route.
is_add_assignable
(The operation is addition followed by assignment, not plus followed by assignment.)
How do you pronounce C++ ? ;-)
If you're going that route, then it's is_plus_equal-able, not is_plus_assignable!
However, += is the add-and-assign operator, even if you might read the symbol aloud as plus-equal.
TCPL uses the following names:
+= add and assign -= subtract and assign *= multiply and assign /= divide and assign
That leads, of course to names like these:
can_add_and_assign can_subtract_and_assign can_multiply_and_assign can_divide_and_assign
Those names don't match the concept names, as Joachim suggested, but they read well.
Hi, I like the can_ prefix but I would remove the and as it could be interpreted as can add can assign. can_add can_assign can_multiply can_post_increase can_left_shift ... can_add_assign can_subtract_assign can_multiply_assign can_divide_assign The same pattern can be used for member functions: can_VERB? We could reserve the has for data or nested type members: has_NOUN? The single problem I see with this traits is that they don't follows the existing naming (see 20.9.4.3) as for example: template <class T, class... struct is_constructible; template <class T, class U> struct is_assignable; template struct has_virtual_destructor; So if we follow this pattern we should name it is_addable is_add_assignable is_post_incrementable Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Review-Type-Traits-Extension-ending-tomor... Sent from the Boost - Dev mailing list archive at Nabble.com.