Re: [boost] Re: is_convertible corner case

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-23 11:26:36

"Peter Dimov" <pdimov_at_[hidden]> writes:

> From: "John Maddock" <jm_at_[hidden]>
>> >From Peter Dimov:
>>
>> >Nope, it says nothing AFAICS. A type cannot be convertible. Only values
>> are.
>> >And you cannot say "a value of type From is implicitly convertible to To
>> >(4.0)" because you need to specify whether that value is an lvalue of
> type
>> >From or an rvalue of type From, and what do l- and r-values mean when
>> >applied to strange (array, reference, function, abstract, etc) types.
>>
>> I refer you back to 4.0p3, which talks about expressions of type T, which
>> are treated as lvalues if the type is a reference, otherwise as an rvalue.
>
> Thanks.
>
> I don't think that 4.0p3 explains everything, though. I doesn't talk about
> expressions of type T. It talks about converting an expression e to type T;
> it then explains that the result of that conversion is an lvalue when T
> ("To" in our case) is a reference type. It says that e is "used as an
> lvalue" if and only if the initialization T t(e) would have used it as an
> lvalue.
>
> This still doesn't solve the "expression of type From" problem since an
> expression can be either an lvalue or an rvalue, and there are no
> expressions of reference types, only expressions that are lvalues. Of course
> I'm not a core expert.
>
> For example, is an expression of type int[4] convertible to int[4]? To int
> (&) [4]? To int const [4]?

If it's any help, here's what John Spicer says:

> David Abrahams <dave_at_[hidden]> writes:
>
>>Hi John,
>>
>>I realize there's a lot of material here, but I wonder if you wouldn't
>>mind taking a look at it all the same?  We're having problems
>>understanding how to talk about the behavior of the is_convertible
>>trait from the type traits library (and standard proposal).  Any
>>guidance you could give would be very helpful.
>>

I'm happy to voice an opinion, although I don't think I
have anything to add that hasn't already been said.

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.

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.

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

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

Hope this is of some use.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution