Boost logo

Boost :

From: Mike Conley (conley.141_at_[hidden])
Date: 2003-04-25 22:32:17

I realize that I'm replying to a message that is now quite old. Hopefully
what I have to say is still relevant. Apologies if not.

"John Maddock" <john_maddock_at_[hidden]> wrote in
> one suggestion was that since only
> expressions (and not types) are convertible to a type or not, that
> is_convertible should be an intrinsic binary operator whose first
> argument was an expression, and whose second was a type. There are two
> key advantages to this approach: it more closely mirrors the text of
> the standard, and therefore standard wording is easier to formulate,
> and that the result can be context sensitive:

Actually, there is another advantage, which (I think) is at least as
important as the ones you cite. Namely, it is possible to define a built
in operator such that is_convertible<Y,X> returns false for

class X{};
class Y : X {};

and ambiguous conversion cases that (as far as I can tell) cannot be
implemented in pure C++ (or even with any existing extension of which I am
aware). That means there's no reason for any ill-formed is_convertible
expressions, other than those involving incomplete types. That seems a
good enough reason by itself to reject the template in favor of a built in

Put another way, the whole point of is_convertible (as I understand it) is
to test a certain property of two types (or a type and an expression, if
you like). In order to perform the test, it should not be necessary to
know whether or not the types or expressions in question satisfy some other
untestible properties.

Any code using the existing template could easily be converted to use a
built in operator. We gain (at least) three distinct and compelling
advantages, and it appears as though we loose nothing. Apart from getting
it standardized, what's the problem?

Mike Conley

Boost list run by bdawes at, gregod at, cpdaniel at, john at