[boost] Re: is_convertible: rationale and wording

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
news:00f101c2c6c6$384586a0$fa2b87d9_at_1016031671: 
> 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 
operator.

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