The issue is not about creating objects or not but about what does it
mean for "a type" to be convertible to another. Personally I have no
idea what the meaning can be. Instead, the standard specifies what it
means for an "expression" to be implicitly convertible to another:
4/3: An expression e can be implicitly converted to a type T
if and only if the declaration ``T t=e;'' is wellformed,
for some invented temporary variable t (8.5).
[Incidentally: this is one of the few places in which the standard
uses "if and only if" where "if and only if" is intended; in other
places it just uses "if" :-( ]
~~~~~~~
Were, going round in circles here: the whole point of this thread was to
clarify the wording, the suggested change was:
"value: defined to be true only if an imaginary lvalue of type From is
implicitly-convertible to type To (4.0). Special conversions involving
string-literals and null-pointer constants are not considered (4.2, 4.10 and
4.11). No function-parameter adjustments (8.3.5) are made to type To when
determining whether From is convertible to To: this implies that a program
is ill formed if type To is a function type, and that if type To is an array
type, then value must necessarily evaluate to false.
The expression is_convertible<From,To>::value is ill-formed if:
Type From, is a void or incomplete type (3.9).
Type To, is not an object or reference type (3.9).
The conversion is ambiguous, for example if type From has multiple base
classes of type To (10.2).
Type To is of class type and the conversion would invoke a non-public
constructor of To (11.0 and 12.3.1).
Type From is of class type and the conversion would invoke a non-public
conversion operator of From (11.0 and 12.3.2)."
Which should pin it down IMO.
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
