[expr.const] Check the result object of a prvalue

[frederick-vs-ja]

Fixes #5422.

The remain issue (modulo CWG2558) is that we shouldn't imply a prvalue is an object, which is not true since C++17.

[lprv]

A prvalue may not have a result object, at least in the scalar case.

[frederick-vs-ja]

A prvalue may not have a result object, at least in the scalar case.

Although temporary materialization doesn't happen in some cases, I think it's harmless to require the result object for the purpose of checking whether the prvalue is a constant expression.

[frederick-vs-ja]

Rebased and force-pushed. @jensmaurer @tkoeppe

[jensmaurer]

I think this is an improvement.

[lprv]

Although temporary materialization doesn't happen in some cases, I think it's harmless to require the result object for the purpose of checking whether the prvalue is a constant expression.

I disagree.

Here, for example, we surely want f() to be a constant expression, but it does not have a result object:

consteval int f() { return 42; };
int x = f() + 1;

The existing wording isn't correct but this change takes it further in the wrong direction.

[jensmaurer]

Ok. Maybe just "result"?

[frederick-vs-ja]

Although temporary materialization doesn't happen in some cases, I think it's harmless to require the result object for the purpose of checking whether the prvalue is a constant expression.

I disagree.

Here, for example, we surely want f() to be a constant expression, but it does not have a result object:

consteval int f() { return 42; };
int x = f() + 1;

The existing wording isn't correct but this change takes it further in the wrong direction.

What's the harm if we require a result object for the determination? Did you mean that if we can't even say "a prvalue whose result object..." without actual temporary materialization? But IIUC in the scalar case, addtional temporary materialization shoudn't be observable.

[lprv]

Ok. Maybe just "result"?

"Result" is synonymous with "value" here, so I don't think that would be an improvement over the current wording.

What's the harm if we require a result object for the determination?

f() in the example above is not "a prvalue ... whose result object ..." (because it doesn't have a result object), and thus not a constant expression under the proposed wording change.

---

If we want to avoid making drastic changes to the structure of the wording here, then I think having to go from 'value' to 'object' in some way or another is unavoidable (sadly), because we don't have a good framework for talking about values (not objects) of class and array types.

Perhaps phrasing the requirements in terms of the constituent values/references of "a hypothetical object initialized from the prvalue" (or something along those lines) could work?

(Then there's also the fact that this paragraph doesn't handle prvalues of type void, but that seems like a separate issue.)

[frederick-vs-ja]

"a hypothetical object initialized from the prvalue"

This is exactly what I'm meaning with "a prvalue whose result object...". Did you mean that we can't just say that if prvalue materialization doesn't happen?

(Then there's also the fact that this paragraph doesn't handle prvalues of type void, but that seems like a separate issue.)

IIUC this is not an issue. The status quo is clear pre-P2686R4 status was that a void expression may be a core constant expression, but is never a "constant expression". There doesn't seem any context where a constant expression is required and its type can be void. (If I'm wrong on this, then perhaps there should be a separate issue.)

Edit: Oops, it seems that P2686R4 accidently madevoid expressions come into picture.

[tkoeppe]

@jensmaurer Assuming this is still good. Let's merge after motions.