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

Subject: Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-03-15 20:11:21

On 3/15/2011 6:37 PM, Vicente Botet wrote:
>
> Vicente Botet wrote:
>>
>>
>> Frédéric Bron wrote:
>>>
>>>> The limitation related to the implicit conversion could maybe be 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.
>>
>>
>
>  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 ambigous
> overload because both the existing operator and the one we provide (with
> argument of type any) need type conversion, so that none is preferred.
> "
>
> Given the trait
>
> template
> struct implicitly_convertible_seq
> {
>    typedef mpl::vector0<>  type;
> };
>
>
> which must be specialized explicitly for each type having implicit
> conversions. We can define on to of the existing interface a trait that
> takes care of implicit conversions
>
> template
> struct has_operator_unary_minus_ext
> { // in pseudo imperative code
>
>    FOREACH t in implicitly_convertible_seq::type
>      if has_operator_unary_minus&lt;RHS, t&gt;::value
>      then
>        typedef true_type type;
>        return;
>      endif
>    typedef has_operator_unary_minus&lt;RHS, RET&gt; type;
> };
>
>
> To take care of the examples in the doc we will do
>
> struct A { };
> void operator-(const A&);
> struct B { operator A(); };
> template<>
> struct  implicitly_convertible_seq
> {
>     typedef mpl::vector  type;
> };
> boost::has_operator_unary_minus ::value; // this is fine
> boost::has_operator_unary_minus::value; // No error: as class A is in the
> list of conversion from B, so boost::has_operator_unary_minus ::value is
> tested before
>
> Let me know if you need some explanations.

This idea looks promising but it would be even more so if your '<' was 
not showing as '&lt;' and you '>' was not showing as '&gt;' everywhere 
in your messages so I could follow it more easily. I do understand what 
you are saying, and it offers a decent workaround even at the price og 
an end-user of a type doing a little more work.

I too am very interested if the "Known Issues" which can cause compiler 
errors when using type traits operators can be solved. or worked around, 
without causing compiler errors.