Frédéric Bron wrote:
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.
Oh, I see.
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.
I will develop it later.
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.
No, it is because the intended behavior on the builtin types is to make an assignment. Remember in C++ user defined types should follow the builtin semantics when possible. 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.