Re: [boost] [type traits] possible bug in boost::is_convertible for types with private copy constructors

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-26 12:33:28

Howard Hinnant wrote:
> On Jun 26, 2008, at 9:19 AM, David Abrahams wrote:
>>
>> Very interesting!  But now the question is, how do we resolve this
>> (and other
>> issues like it that will surely come up) for Boost?
> 
> I don't think there is any one answer.  Sometimes namespaces are the
> answer.  boost::X need not be the same thing as std::tr1::X which need
> not be the same thing as std::X.

But boost::tr1::x had better match match std::tr1::x

> In this particular case, I would expect a vanishingly small amount of
> code to be broken by changing from the boost::is_convertible spec to the
> std::is_convertible spec.  If something is convertible from an lvalue,
> then it is usually convertible from an rvalue.  Obviously this statement
> can be refuted with an example such as:
> 
> struct A
> {
>     A(B&);
> };
> 
> But I am asserting that the above code is sufficiently rare, especially
> when combined with the use of is_convertible.
> 
> For most uses of is_convertible, it does not matter whether the source
> is considered an lvalue or an rvalue (pointers probably make up most of
> the use cases).  For those remaining cases where it does matter, most of
> those want to consider the source an rvalue (move-only types).  And in a
> context where the "from" is a perfectly forwarded template,
> [temp.deduct.call]/3 assures that is_convertible considers the "from"
> with the same l/r-valueness as the argument being passed to the deduced
> template:

At least one thing is clear: is_convertible shouldn't ever cause a
compile-time error.  If one of the possible implementations always
avoids a compile-time error, I vote for that one.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com