Repository navigation
CWG2981 [expr.arith.conv] 0 < 0 is an int #663
Description
Reference (section label): [expr.arith.conv] pargraph 1
Issue description
[expr.rel] paragraph 2 states that the result of the relational operator for e.g. 0 < 0 is bool. This is subsequently contradicted by [expr.rel] paragraph 3, which states that the usual arithmetic conversions are applied, and [expr.arith.conv] paragraph 1 states:
The purpose [of the usual arithmetic conversions] is to yield a common type, which is also the type of the result.
If paragraph 3 supersedes paragraph 2, then 0 < 0 is of type int.
Suggested resolution
Update [expr.arith.conv] paragraph 1 as follows:
Many binary operators that expect operands of arithmetic or enumeration type
cause conversions and yield result types in a similar way.
The purpose is to yield a common type
-, which
+; unless otherwise stated, that common type
is also the type of the result.
This pattern is called the usual arithmetic conversions, which are defined as follows:
Activity
eisenwave commentedon Jan 2, 2025
I'm not really sure what the intended wording strategy here is. https://eel.is/c++draft/expr.mul chooses to say that:
But why wouldn't the usual arithmetic conversions determine the result by default? [expr.arith.conv] simply states what the result is, and that wording isn't conditional on "if stated to determine the type of the result". Also note that [expr.add] relies on the type of
0 + 0being determined by the usual arithmetic conversions without this being stated explicitly; it is nowhere stated in [expr.add] what the type of0 + 0is.In short, we end up with three cases at least:
On another side note, I couldn't find any wording which states what the value category of
0 + 0is.My preferred overarching fix would be to purge the practice of using [expr.arith.conv] to determine the result type completely (it's weird, done inconsistently, and doesn't save that much wording elsewhere anyway), and that could be done as an editorial fix once normative wording problems are fixed.
jensmaurer commentedon Jan 2, 2025
I think we should limit "usual arithmetic conversions" to exactly that: conversions on the operands. The result type (and value category) should be specified by each individual operator.
eisenwave commentedon Jan 2, 2025
You know what, I think I'll just make a paper for that.
jensmaurer commentedon Jan 2, 2025
Why a paper? I certainly want a bit of CWG review on the change, but this feels entirely like a core issue.
eisenwave commentedon Jan 2, 2025
Because the blast radius is pretty large here, and I think as a drive-by fix, we should also specify the value category where needed. I'll look into how big of a change that really is first. I guess I can post the diff here and see if that needs a paper.
In the end, we should clearly state that e.g.
x + yfor integers is a prvalue of the common type after usual arithmetic conversions.jensmaurer commentedon Jan 2, 2025
9 places (max) need updates.
eisenwave commentedon Jan 2, 2025
Suggested resolution v2
Update [expr.arith.conv] paragraph 1 as follows:
Editor's note: While it's not incorrect that result types are also often yielded in a similar way, it's not always the case (e.g. [expr.rel], [expr.eq]), and we should purge any mention of result types if these conversions aren't stated to determine the result anyway.
Update [expr.mul] paragraph 2 as follows:
Update [expr.add] paragraph 1 as follows:
Update [expr.rel] paragraph 2 as follows:
Editor's note: Since we state that
falseortrueare always yielded, this is only an editorial fix. Nonetheless, we should do it for consistency here. This core issue introduces "prvalue of type" wording for every case that was previously covered by the usual arithmetic conversions, and so updating this part of [expr.rel] should be within its scope.Update [expr.eq] paragraph 7 as follows:
Update [expr.bit.and] paragraph 1 as follows:
Update [expr.xor] paragraph 1 as follows:
Update [expr.bit.or] paragraph 1 as follows:
jensmaurer commentedon Jan 2, 2025
CWG2981 with suggested resolution adjusted to be consistent with [expr.cond] p7.2
[-][expr.arith.conv] `0 < 0` is an `int`[/-][+]CWG2981 [expr.arith.conv] `0 < 0` is an `int`[/+]