Re: [boost] Re: is_convertible corner case

From: John Maddock (jm_at_[hidden])
Date: 2003-01-23 07:15:10

> >Well the wording in the standardisation proposal says:
> >
> >"value: defined to be true only if type From is implicitly-convertible to
> >type To (4.0).
> >
> >Which really says it all IMO (by reference to section 4.0 of the
standard.
>
> Gulp! In the ISO proposal???

OK it needs tightening up: in particular the preconditions need specifying
(To must not be a void, function, incomplete or abstract type, From must not
be void), and it should probably say "value: defined to be true only if an
expression of type From is implicitly-convertible to type To (4.0)."
Getting the wording right is difficult, but the semantics are intended to be
the same as 4.0p3.  Personally I would be happy if it were a precondition
that neither To nor From were void types.

>It makes sense only if you want it to make sense. That is, like almost
>all other cases, it depends on your definition of is_convertible,
>which is exactly what we miss. The fact that I had to ask means that
>the definition in the documentation is not enough, and that I must *as
>a library user* go to look at the implementation to see what happens
>in my special case. The problem is that even then I remain in doubt:
>is this just a "chance" due to the way they have implemented it or is
>it intentional? If they'll change the implementation in the future can
>the value be different so that my code is unexpectedly broken?

I agree, there should be no special cases, the wording should refer only to
the standard, not to the implementation.

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

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