Re: [boost] review request: addition to type_traits library ofhas_operator_xxx

Subject: Re: [boost] review request: addition to type_traits library ofhas_operator_xxx
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-11-20 10:35:57

On 11/20/2010 5:01 AM, John Maddock wrote:
> My apologies for coming late to this discussion, I appear to have
> reached my "bandwidth limit" for the max number of simultaneous
> discussions - not that that's all that hard :-(
>
> A couple of observations:
>
> * I'll go with the consensus on naming, and if that means changing the
> names of existing traits, then so be it - as long as the names that are
> part of the std draft remain unchanged.

I personally feel this should be avoided because of it confusing and 
irritating end-users who already may be using any current name in their 
code, as well as differing from the std draft. Unless of course some 
name were a complete misrepresentation but I do not think that is the 
case discussed.

> * Personally I prefer either has_XXX_operator or has_operator_XXX to the
> namespace approach. The latter has the advantage of grouping all the
> operator test names together in the alphabetical index, the former reads
> easier and more descriptively to me (we can always add a new section to
> the "type types by category" section of docs). But <shrug> I guess.
> * I'm not that keen on the operators:: subnamespace, to me that
> namespace is reserved for the operators library
> http://www.boost.org/doc/libs/1_45_0/libs/utility/operators.htm it would
> have to be boost::type_traits::operators I guess which is rather less
> cute :-(

I forgot about this when I made my suggestion. I myself would not find 
boost::type_traits::operators to be too onerous, since after all one 
could alias the namespace as one likes, but I am a much stronger 
proponent of clarity in reading code than how much I have to type and 
many others seem to find important how many letters they have to type to 
use something in their code.

> * If boost::is_convertible doesn't work as required for this library,
> then we should fix it, not reinvent it. We already have a lot of
> compiler workarounds and acumulated knowledge in that version, it would
> be a shame to loose that by reinventing the wheel.
>
> Other than that, it would be really good to finally see comprehensive
> operator testing in type_traits.

Very much agreed. I want/need these for a possible Boost library I still 
have held off putting in the sandbox until this was finished. So I will 
be very personally happy if Frederick Bron's work gets reviewed.