Bug 1626 – bool spec problem

According to : http://www.digitalmars.com/d/1.0/expression.html NumericLiteral is right under Primary Expressions As we all know int i=3; if (i) {} above is valid D code. And right in: http://www.digitalmars.com/d/1.0/statement.html#IfStatement IfCondition is either Expression,auto Identifier = Expression, or Declarator = Expression The situation here that "i" is an Expression. and in the IfStatement part spec says: "Expression is evaluated and must have a type that can be converted to a boolean." I *assume* boolean here means bool, and it should be bool. So expression here can be *implicitly* convert to bool. But: bool b=3; fails as expected with message "Error: cannot implicitly convert expression (3) of type int to bool" 3 is NumericLiteral therefore Primary Expressions, i.e. 3 is an Expression. And the statement I concluded tells "expression can be *implicitly* convert to bool" so should 3 be implicitly converted to bool? I hope not. The error message is obviously designed by Walter. So maybe something more should be done to the spec.

I think it's clear, in that it says "must have a type that can be converted to a boolean". It doesn't say "must have a type that can be *implicitly* converted to a boolean", because that's not the case. The type needs to be convertible in that if you cast it to bool *explicitly*, it works. C.f. the following: bool b = cast(bool)3;

I think you miss the point if( 3 ) { } works And in the spec: "Expression is evaluated and must have a type that can be converted to a boolean. If it's true the ThenStatement is transferred to" Notice: If it's *true* the ThenStatement is transferred to So what's *true*? I would think the evaluated result of the specific expression. And what type can have value *true*? bool is the answer. Therefore, the expression is not only a type that *can* be converted to a boolean, but also a type already be converted to a boolean. So the convertion here is implicitly.

(In reply to comment #2) > I think you miss the point > if( 3 ) > { > } > works > And in the spec: > "Expression is evaluated and must have a type that can be converted to a > boolean. If it's true the ThenStatement is transferred to" > > Notice: If it's *true* the ThenStatement is transferred to > So what's *true*? I would think the evaluated result of the specific > expression. > And what type can have value *true*? bool is the answer. Read "it" as "cast(bool)Expression". So, "if cast(bool)Expression is true". So, of course it's bool. > Therefore, the expression is not only a type that *can* be converted to a > boolean, but also a type already be converted to a boolean. So the convertion > here is implicitly. Yes, it is a type which can be converted to a boolean, and yes, the conversion is done implicitly. But no, it doesn't have to be implicitly convertible. An explicit cast is implicitly inserted. I'll leave this open now, so somebody with access to the doc can make of this what they will, but I don't see the problem.

Something like this could be added to Statements/If Statement to make the spec describe DMD's behavior: If the condition expression v that is passed to the if statement is not of type bool, a different expression depending on v's type is evaluated instead: * integer, floating point, complex, pointer, function: v != 0 * array: v.ptr != 0 * associative array: cast(void*)v != 0 * delegate: v.funcptr != 0 * class: v !is null * struct: error Note that for struct and class type conditions, it is not equivalent to evaluating cast(bool)v.

I don't think there's a problem. "Can be converted" doesn't mean "implicitly convertible". Implicitly convertible means something very specific, and that term would have been used if it was meant. Will mark as "wontfix".