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: Daniel Herring (dherring_at_[hidden])
Date: 2011-03-29 12:08:51

On Tue, 29 Mar 2011, Frédéric Bron wrote:

>> 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).

Those names are a bit long...  Here are some brainstormed names.  I 
reduced "operator" to "op" for uniform brevity.

assert_op_equal_to
affirm_op_equal_to
can_call_op_equal_to
check_op_equal_to
confirm_op_equal_to
detect_op_equal_to
find_op_equal_to
has_op_equal_to // implies the operator belongs to a class..
have_op_equal_to // better form of the verb
probe_op_equal_to
test_op_equal_to
trait_op_equal_to
verify_op_equal_to

Reducing underscore counts is good for the fingers.  Here are a few 
options there.  I picked "check" for uniformity.  Most of the prefixes 
above would also work.

check_op_equal_to // base X_op_Y form

check_opequal_to

opcheck_equal_to
checkop_equal_to

check::op_equal_to
check_op::equal_to

Again, I'm still not seeing the predicates for operators like "," and 
"->".  Was that by design?  (Sorry; I missed most of the conversation.)

- Daniel