> >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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost