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?
You are right, void means "do not check" as stated in the documentation: "The default behaviour (RET=void) is to not check for the return value of binary operator+. Be careful that it does not mean that operator+ must return void to have the trait derive from true_type."
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.
It is fair to add this in the known issues, even if it is already explained before.
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?
Unfortunately I need a l-value, espacially for += type of operators.
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.
I cannot comment on that as I do not see exactly how this would be implemented. Sorry.
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.
You are right. I copied the structure of some other traits found in the type trait library. But as I am already in a detailed namespace (boost::detail::has_operator_unary_minus_impl), I can choose the same names for all operators inside these dedicated namespaces.
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
Why? is it to avoid confusion with "equal to"? I like plus_equal because plus is a sign and equal is also a sign. So I think it is easier to remember. Frédéric