[boost] Re: is_convertible corner case

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-01-25 10:33:07

On Sat, 25 Jan 2003 12:17:18 -0000, "John Maddock"
<jm_at_[hidden]> wrote:

>> A string literal (narrow or wide) is an lvalue.
>
>Yes, you're right, however it's still a non-issue: array to pointer
>conversions are allowed (int[2] to const int* for example)

Yes, but the special conversion is from const char[N] to char*, not
const char*.

>Absolutely, sorry I meant "that's a really nasty corner case", no slur on
>you intended.

It's all right for me :-)

[...]
>A conversion is possible but would use a non-public constructor - the code
>must not compile.
>A conversion is possible but would use a non-public conversion operator -
>the code must not compile.
>A conversion is possible but is ambiguous - the code must not compile.
>
>It's the last three cases (and exactly which situations produce them) that
>we are agonising over.  It doesn't matter whether you use a class template
>or an operator, you can't make these cases do anything meaningful.  Perhaps
>I should have said "ill formed" rather than "undefined", I'm still learning
>the right terminology...

Yes, I agree that they should be ill-formed. The problem is, as we
have repeatedly pointed out, that the template implementation isn't
adequate if is_convertible<>::value may depend on the context, because
of possible violations of ODR. A built-in operator would solve the
problem. Also, if you stick to expressions as source, the function
templates seem to work (unless we discover some other problem with
them too). Again, I like the approach to not put in the core language
facilities that can be implemented with normal code but the order is:
first I see what I want to get, then I see if it can be implemented.
Here we seem to do the inverse: we see what can be done in current
C++, and if it is not enough (because I can't do access checking) we
are contented anyway. Seems a surrogate to me.

Genny.