[boost] Re: Re: Re: Re: Re: Re: is_convertible: rationale and wording

From: Mike Conley (conley.141_at_[hidden])
Date: 2003-04-27 14:17:51

David Abrahams <dave_at_[hidden]> wrote in
news:ur87n26nf.fsf_at_[hidden]: 

> Mike Conley <conley.141_at_[hidden]> writes:

>> OK, this is wrong.  What I wanted was a boolean test:
>> is_const<T>::value && is_convertible<T,int>.  That's not what and_
>> does.  Duh. 
> 
> Yes it does.

Well, it applies is_convertible, which doesn't make much sense for a 
built in operator (which wouldn't have a member ::value).

 
> So will it be illegal to build a trait which tests is_convertible on a
> dependent type?  If so, is_convertible is fragile and dangerous.
> If
> not, then you have to compute is_convertible on a non-dependent type,
> which makes is_convertible almost useless.

I imagine it would be used as a default template parameter:

template <class T,
                 bool int_convertible = is_convertible<T,int> >
struct ...

The complication is that the compiler would have to be smart enough to 
know it might need to instantiate the template again if the value of 
is_convertible<T,int> changes.  And code like your 
is_const_and_int_convertible example would potentially violate the ODR.

Maybe the best thing to do is ignore context and stick with the behavior 
of the template (minus, hopefully, the compiler errors it can cause).

-- 
Mike Conley