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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk