Re: [boost] Re: is_convertible corner case

From: John Maddock (jm_at_[hidden])
Date: 2003-01-24 07:35:27

>    One is conversion to a pointer type: in this case you can have
>    a source expression of any integer type, but it must be constant
>    and have the value zero. Example:
>
>        int * p = '\0';
>
>        enum { e = 5 };
>        int (*pf)() = 4 % ( e - '\001');
>
>    If you use the indeterminate article "a"/"an" in the wording above
>    ("an" rvalue of type From) does it mean: "all" expressions of type
>    From or "at least one" expression of type From? Of course, to
>    exclude int->pointer-to-object convertibility one would say "all"
>    expressions, but I'm not sure whether this is ok for UDTs.
>
>
>    The other case is the deprecated conversion const char [N] -> char*
>    which is valid only if the source expression is a string literal.

OK, both of those are special conversions of literals - I think we can
dismiss these by taking John Spicer's suggestion, and saying that the source
type is an lvalue of type From.  (in other words is_convertible does not
detect those conversions).

>
> - Another point that I would like to understand is "where"
> convertibility is checked. Currently convertibility is checked in the
> scope of is_convertible<> but is this the intent? This makes a
> difference when you have e.g. a private conversion operator:
>
>
>   class X {
>       operator int(); // private
>       friend class Y;
>   };
>
>   class Y {
>       void f() {
>           is_convertible<X, int>::value;  // true or false??
>                                           // or error?
>       }
>   };

Now that one is just plain nasty :-(  It's a similar problem to what happens
if the To type has a private constructor taking the From type, my gut
feeling is that both these cases have to be listed as "undefined behaviour".
Clearly is_convertible<T,U>::value must have a single value under the one
definition rule, so there can be no ambiguous context-sensitive answers.

Thanks for bringing these up, I'll try and produce some better wording over
the weekend, and then I'll see if you guys can shoot it down again :-)

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm