CWG3136 [expr.const] void constant expressions

[leni536]

Full name of submitter (unless configured in github; will be published with the issue): Lénárd Szolnoki

Reference (section label): [expr.const]

Issue description: prvalue void core constant expressions should be constant expressions

A constant expression is either:

• a glvalue core constant expression E for which
  ...
• a prvalue core constant expression whose result object ([basic.lval]) satisfies the following constraints
  ...

A prvalue core constant expression of type void has no result object, therefore it's missing from the list. My reading is that such core constant expressions are not constant expressions.

Therefore the following program is ill-formed:

consteval void foo() {}

int main() {
  foo(); // immediate invocation must produce a constant expression
}

GCC, clang and MSVC accept this program (https://godbolt.org/z/Tfjeh3eTo).

In addition, the expression corresponding to a consteval-block-declaration is also a prvalue expression of type void, which "shall be a constant expression" [dcl.pre].

Suggested resolution:

Add the following point under "A constant expression is either:"

• a prvalue core constant expression of type void.

[eisenwave]

a prvalue core constant expression whose result object ([basic.lval]) satisfies the following constraints

If a core constant expression has no result object (and [basic.lval] explicitly points out that void expressions have none), then the requirement is vacuously satisfied: if there is no result object, there are no requirements to be satisifed. Therefore, there isn't really a wording defect.

It would be more clear if we said

... whose result object ([basic.lval]), if any, satisifes ...

That seems like an obvious and tiny change that can be done editorially.

[lprv]

If a core constant expression has no result object (and [basic.lval] explicitly points out that void expressions have none), then the requirement is vacuously satisfied: if there is no result object, there are no requirements to be satisifed.

I don't agree with this reading. An expression that has no result object is not an "expression whose result object satisfies [some] constraints". The addition of "if any" would change the meaning of the sentence.

Not all (non-void) prvalues have result objects, so this wording defect reaches further than just void expressions (and "if any" would not be a correct fix, since we still want to check the value of non-void expressions).

Relevant: cplusplus/draft#6267 contains some previous discussion of this.

[eisenwave]

Not all (non-void) prvalues have result objects, so this wording defect reaches further than just void expressions (and "if any" would not be a correct fix, since we still want to check the value of non-void expressions).

Yeah right,

The result object of a prvalue is the object initialized by the prvalue

so if you don't initialize anything, there is no result object, and you don't get a constant expression. This means that (0, 0) is also not a constant expression because the left 0 has no result object, but is a prvalue that is evaluated.

[leni536]

This means that (0, 0) is also not a constant expression because the left 0 has no result object, but is a prvalue that is evaluated.

The left 0 is not required to be a constant expression for the whole (0, 0) to be one.

[eisenwave]

Anyhow, I don't really see a concrete example for why adding "if any" wouldn't be correct. There are expressions without result objects, like 0 in a comma operator, but it seems like we're not checking their result objects for satisfaction of requirements anywhere in the wording anyway, so that simpler change seems correct.

... Actually bad example; the left side of a comma operator is a discarded-value expression, so temporary materialization is applied and you end up with some object. I can't think of an example then.

Update: cplusplus/draft#6267 has some examples. I guess 0 + 0 doesn't have result objects for the 0s.

[leni536]

Anyhow, I don't really see a concrete example for why adding "if any" wouldn't be correct.

consteval const int* foo(const int& x = 1) {
    return &x;
}

int main() {
    foo() + 1;
}

https://godbolt.org/z/re6eb8fW9

foo() doesn't have a result object, but it's an immediate invocation that shall be a constant expression. You want to check the value, even if it doesn't have a result object.

[eisenwave]

I get the example, and adding "if any" works in that case. It does cover the void case just fine, just like your solution, but in fewer words.

If we go by Iprv's interpretation, which is that you only have a constant expression when there is a result object, then foo() is not a constant expression due to having no result object, and that's clearly broken. My "if any" solution fixes that, although it also means we're not running any checks on the result, which is also defective.

In any case, both your added bullet and my "if any" solve the void case while leaving the "result object" issue defective.

[frederick-vs-ja]

For a prvalue constant expression of an object type without result object created, in cplusplus/draft#6267, @lprv suggested to use "a hypothetical object initialized from the prvalue" for such an expression, although I believed "whose result object" could mean the same thing.

We have never explicitly mentioned void constant expressions in [expr.const], see [expr.const]p22.2, N4950 [expr.const]p13, and P2686R5. As a result, void expressions can be accidentally covered or uncovered in evolution. This wasn't an actual issue until the introduction of immediate functions.

The most promised resolution to me is to explicitly specify void constant expressions.

[jensmaurer]

CWG3136

A prvalue of scalar type is just a "value"; it doesn't initialize an object. The "if any" approach solves that, too.

[leni536]

The "if any" approach solves that, too.

In my reading the "if any" wording doesn't put any requirements on the value if there is no result object, therefore it makes the following program well-formed:

consteval const int* foo(const int& x = 1) {
    return &x;
}

int main() {
    foo() + 1;
}

[katzdm]

What do y'all think of the following?

a prvalue core constant expression that either has type cv void or whose computed value or result object ([basic.lval]) satisfies the following constraints:

[leni536]

What do y'all think of the following?

a prvalue core constant expression that either has type cv void or whose computed value or result object ([basic.lval]) satisfies the following constraints:

I think this is incomplete, because constituent-value is only defined on objects, and not on values. https://eel.is/c++draft/expr.const#2

[jensmaurer]

Yes. The definition of "constituent value" says

"The constituent values of an object o are ..."

In the case of a scalar return value, there is no "object" (not even a result object), there are just (computed) "values" per https://wg21.link/basic.lval#1.2 .