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