Re: [boost] Re: is_convertible corner case

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

> I think that is_convertible should be based as closely
> as possible on the definition in clause 4 of the
> standard.  As has been pointed out, a problem with this
> is that the standard refers to a source expression, not
> a source type.  I think this means that the definition
> of is_converible needs to say something like "True if
> an lvalue of type From can be converted to type To
> according to 4p3" (or make it an rvalue, but you have
> to pick one).  You could, of course, have two versions
> of is_convertible to handle both lvalues and rvalues.

You're right, and I think that lvalue is the right choice, as it closely
mirrors what the implementation does, as soon as you get into rvalues you
end up with ambiguous answers due to things like the NULL pointer conversion
(thanks to Genny for spotting that one).

> A few miscellaneous comments:
>
> - There are no expressions of reference type, so
> presumably a reference on the from type should be
> ignored (which it would based on a definition that used
> an expression having type From.

I don't think we need to say that, although in practice any reference
decoration will be ignored.  Internally is_convertible will probably convert
>From to a reference so that it can handle abstract and function types.

> - There were several mentions of prohibiting abstract
> types.  Expressions of abstract class type can be the
> source of an implicit conversion, however.

Yes, they are only prohibited for the destination type.

> - There was a mention of special treatment of parameter
> types that are arrays. I don't think this is an issue
> as you are dealing with types and even if you declare a
> parameter of type X[], it has type X*.

For function parameters yes, but 4.0 talks about initialisation, and in any
case conversions take place in many contexts, not just function parameter
passing, so:

int a[2];
int b[2];
a = b;  // invalid int[2] not "convertible" to int[2]

I'm beginning to think that the only way to deal with this is to add array
types to the list of types banned from the "To" parameter.  Otherwise we get
into the old context sensitive answer problem.

Thanks,

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