Re: [boost] Re: is_convertible corner case

From: John Maddock (jm_at_[hidden])
Date: 2003-01-25 07:17:18

> 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), so this will do
the right thing anyway.  The string literal to pointer conversion is just a
special case of a more general conversion, or am I still missing something?

> >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?

Absolutely, sorry I meant "that's a really nasty corner case", no slur on
you intended.  I would much rather that these issues were brought up now,
than submitted as DR's later!

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

I don't think these solve anything, there are five cases that need to be
considered:

No conversion is possible.
A conversion is possible.
The target type is not an object or reference type - the code must not
compile.
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...

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

Again, thanks for the all comments.

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