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