[boost] Re: is_convertible corner case

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-01-24 13:48:05

On Fri, 24 Jan 2003 12:35:27 -0000, "John Maddock"
<jm_at_[hidden]> wrote:

>>    One is conversion to a pointer type: [..]
>>
>>    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).

A string literal (narrow or wide) is an lvalue.

>>
>> - 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 :-(

Sorry. That wasn't my intention. It's just that I take the issue
seriously (as you certainly do as well). I know, it is unpleasant to
discover complications in something that seemed so simple and elegant,
but we must do it. Better discovering problems now than late, don't
you think?

>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".

Ouch, no. You will never find me agreeing on this point. This seems
along the lines of "if I can't get it work, then it's undefined
behavior" which is a habit we should all get out of. As Paul
Mensonides wrote me (Paul, I hope you don't mind the quotation), UB is
reasonable e.g. when diagnosing the situation is impractical (for the
compiler), or when platform differences make it difficult to choose a
single specification without penalizing some of them, not when just we
don't know what to do. In this case, I'm under the impression we are
trying to implement something within the existing language that should
actually be a built-in operator. I think the question is: do we need
is_convertible<> for generic programming? If so, can it be implemented
in current C++? No? Then make it an operator. I appreciate the
philosophy of C++ of avoiding putting in the core language what can be
implemented in the library but, hey, if it can't then you can't! :-)

Maybe half-ways between a built-in is_convertible operator and a
library implementation are possible: e.g. you could have two
non-member template functions:

  namespace  std {

    typedef char (&no_type)[1];
    typedef char (&yes_type)[2];

    template <typename T>
    struct identity { typedef T type; };

    template <typename To>
    no_type is_convertible(...);

    template <typename To>
    yes_type is_convertible(typename identity<To>::type);

}

This is already a useful facility to check convertibility of
expressions. Once you have it, you can use it for types too as long as
you have an operator that, given a type, gives you the expression to
pass to std::is_convertible

  std::is_convertible<To> ( expression(From) )

That's just a rough idea, of course.
Also, it would be nice to have, as syntactic sugar, a shortcut for
testing sizeof(std::is_convertible...) against sizeof(no_type) and
sizeof(yes_type), e.g.:

  is_true ( std::is_convertible(char) (expression(int)) )

But then you already have two new operators (ok, is_true isn't
strictly necessary, and could be a macro ;-)), so why not making
is_convertible an operator instead? It remains however that is_true
would be handy in itself, and that I would like no_type and yes_type
to be standardized.

>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 :-)

Well, as I said the intent was quite the contrary than being
destructive. I'll look forward for the new wording :-)

Genny.