Hi, Thanks Frédéric for proposing this waited for long time extension. if I have understood there is no mean to check if an operator or a function returns void. void has been used as default value for the RET type to don't check the return type, isn't it? If this is the case, this should be included in the limitations, as others could think that we can check for this, as other post let think. There is a declval function on Boost.Utility that creates a rvalue reference that could be used instead of the make() function. Please could you check if this function is adapted to your needs? The limitation related to the implicit conversion could maybe reduced if the traits take care of a special trait giving the list of classes that a class is implicitly convertible to implicitly_convertible_seq::type With this trait the has_operator_name traits could try to check before in this type sequence to avoid the ambiguity. The main problem is that this trait needs to be specialized for each class only once in a centralized way, which is quite restrictive. Of course this can be defined on top of the existing traits, so it is not a blocking issue for me, but I would like to know what other think of the approach. Just a last comment on the name of the structures used in the detail and specific namespace. Instead of repeating the name you could just use shorter names, e.g. namespace detail { namespace has_operator_unary_minus_impl { // ... // defines some typedef for convenience template < typename RHS, typename RET > struct has_operator_unary_minus_impl { typedef typename ::boost::remove_reference::type rhs_noref; typedef typename ::boost::remove_cv::type rhs_nocv; static const bool value=(has_operator_unary_minus_impl1 < rhs_noref, RET, ::boost::is_pointer< rhs_noref >::value >::value); }; } // namespace has_operator_unary_minus_impl } // namespace detail could be replaced by namespace detail { namespace has_operator_unary_minus_impl { // ... // defines some typedef for convenience template < typename RHS, typename RET > struct helper_0 { typedef typename remove_reference::type rhs_noref; typedef typename remove_cv::type rhs_nocv; static const bool value=(helper_1< rhs_noref, RET, is_pointer< rhs_noref
::value >::value); }; } // namespace has_operator_unary_minus_impl } // namespace detail
Last I agree that the use of equal should be replaced by assign when assignment is intended += has_operator_plus_equal -> has_operator_plus_assign -= has_operator_minus_equal -> has_operator_minus_assign Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Review-Boost-Type-Traits-Extension-by-Fre... Sent from the Boost - Dev mailing list archive at Nabble.com.