Re: [boost] [Review] Type Traits Extension ending tomorrow

Subject: Re: [boost] [Review] Type Traits Extension ending tomorrow
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-03-18 15:54:26

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-tomorrow-tp3383782p3388254.html
Sent from the Boost - Dev mailing list archive at Nabble.com.