Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision

Subject: Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-03-29 14:46:56

2011/3/29 Frédéric Bron <frederic.bron_at_[hidden]>:
>> I like can_can_operator_XXXX. Have you considered can_call_XXXX_operator?
>> BTW, I don't see in the review result any constraint on the names for XXXX. I'm designing Boost.Opaque that provides some meta-function to forward the operators from the opaque class to the underlying type such as using_XXXX, hiding_XXXX and I would want to use the same as in your library. Please, could you give the list of XXXX that will be provided by the library?
>
> I have updated this page for this (last column of the table):
> https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
> This is my current proposal which is very close to Boost.Proto apart
> for pre/_inc/dec->pre/post_increment/decrement and negate->unary_minus
> (to keep symmetry with unary_plus).

Standard and boost (proto, accumulator, phoenix, ..., boost::operator:
"negatable") agree on "negate". Why celebrate diversity here?

> If I do not see too much yuk on this proposal by end of this week
> (Sun. April, 3rd), this is what I am going to use.

I don't think component "operator_" should be inserted. The prefix
"can_call_operator_" accounts for over 60% of information of the
proposed names. Name components shall only be added, if they carry
indispensable information. Yet the fact, that we deal with operators
here is completeley clear from the context of use.

Apart from that I think can_call_xxxx is o.k. and I can also live with
is_callable_xxxx
has_xxxx

Regards,
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de