Re: [boost] RE [Boost-announce] [Review] Boost.Type Traits Extension by Frederic Bron

Subject: Re: [boost] RE [Boost-announce] [Review] Boost.Type Traits Extension by Frederic Bron
From: Frédéric Bron (frederic.bron_at_[hidden])
Date: 2011-03-15 05:00:37

> a. For the assignment operators (for example +=) the name proposed is
> of the form has_operator_<op>_equal (for example
> has_operator_plus_equal). Wouldn't has_operator_<op>_assign (for
> example has_operator_plus_assign) be more intuitive?

Why? is it to avoid confusion with "equal to"?
I like plus_equal because plus is a sign and equal is also a sign too. So
I think it is easier to remember.

> b. From the documentation: There is an issue if the operator exists
> only for type A and B is convertible to A. In this case, the compiler
> will report an ambiguous overload.
> Couldn't this be mitigated by changing the default for the result type
> from void to the type as in <functional>?

This is not related to the return type. Only to the arguments of the operator.

> For example:
> has_operator_unary_minus < class RHS, class RET=RHS >
> has_operator_minus_assign < class LHS, class RHS=LHS, class RET=LHS >
> This would take care of most of the normal use cases.

I think it is best to have the default behavior to forget about the
return type. Why would you impose return type to be LHS?
It is fine for +, -, ... when RHS=LHS but when you start to deal with
different types, I think it just adds confusion.
has_operator_plus<double, int> would then check for a return type
"double" while has_operator_plus<int, double> for a return type int.
You would break the symmetry of these operators.
Also what about dereference operator?

Regards,

Frédéric