Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Barend Gehrels (barend_at_[hidden])
Date: 2011-04-21 16:50:47
On 21-4-2011 21:42, Stewart, Robert wrote:
> Barend Gehrels wrote:
> Yet another round. Oh boy. I'll address the points you (re)raised, but I plan to stop after this. There's really not much more we can say, unless there's a sudden epiphany.
Sorry about the other round, but the supports_ is new (I checked) and
maybe (didn't check) the relation of prefix/naming and why they are related.
As you felt sorry about not being part of the proto review, I think I
may take this chance to add something to the type traits after-review,
now that it is not yet written in stone and the discussion was revived
>> There are two things: the names and the prefix. And they are
>> About the prefix: I don't like can_call_. It is novel as
>> Joachim says, and AFAIK not widely used, and looking a bit
>> awkward (in my opinion). In such cases I normally use
>> "supports", so: supports_addition, supports_equal,
>> supports_not. It is not shorter (neither longer) but reads more
> "can_call_" is novel, but I don't find it awkward.
> "supports_" is a bit vague, but passable.
I'm not a native speaker, but for me they bear the same meaning. But
I've never seen can_call before.
>> Next step: then "has_" is more convenient, because complying to
>> existing practice. So: "has_operator_not". Perfect.
> Nope. As has been noted before, that implies ownership. A global operator doesn't belong to anything, so nothing "has" the operator.[...]
Thanks for your explanations. I think that supports_ works right.
You are right about ownership, I didn't read all the previous
discussions, and didn't realize this when writing my mail, sorry about
that. So, of course, the has_ prefix is indeed not logical for those
cases. Is it, by the way, possible to distinguish between these cases or
has that been discussed before as well?
About the mixtures, yes, plus and multiplies, modulus and percent,
right. It is not perfect. But I doubt if we therefore should invent
another operator list again... But I admit, the can_call works about
However, I'm still finding can_call inconvenient, so "supports_" is my
only suggestion left (actually that was the reason for me to react on
that operator list). Then without operator to avoid the mixture.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk