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
> * 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk