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

Subject: Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron
From: Frédéric Bron (frederic.bron_at_[hidden])
Date: 2011-03-15 04:38:42

> 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