[dcl.pre] In a `static_assert` message, `data()` often does not produce a core constant expression

[cor3ntin]

P2741R3 user-generated static_assert messages specifies that

if the static_assert-message is a conditional-expression M,
– M.size() shall be a converted constant expression of type std::size_t and let N
denote the value of that expression,
– M.data(), implicitly converted to the type ”pointer to const char”, shall be a core
constant expression and let D denote the converted expression

However, consider

struct array {
    constexpr unsigned long size() const {
        return 2;
    }
    constexpr const char* data() const {
        return d_;
    }
    const char d_[2];
};
static_assert(false, array{'a', 'b'});

This static_assert message does not (but should) satisfy the requirements.
The issue here is that std::array<char, 2>{'a', 'b'}.data() produces a pointer that contains the address of an object that does not have static storage duration. In fact it returns a pointer to a subobject of a...temporary?

[dcl.pre] Should establish that

• the expression M produces a temporary object that is usable in constant expression (and whose lifetime ends when the message is produced?)
• Maybe not say anything about M.data() being a constant expression - only M.data()[N] which definitely needs to be a constant expression.
• Alternatively, establish that all of these evaluations happen in the same context, although this seems more complicated.

[frederick-vs-ja]

The issue here is that std::array<char, 2>{'a', 'b'}.data() produces a pointer that contains the address of an object that does not have static storage duration. In fact it returns a pointer to a subobject of a...temporary?

I think std::array<char, 2>{'a', 'b'}.data() is still a core constant expression ([expr.const] p5). It merely fails to satisfy the conditions for a constant expression ([expr.const] p13).

• the expression M produces a temporary object that is usable in constant expression (and whose lifetime ends when the message is produced?)

Hmm... this is not suitable for a std::string that is too long to fit into the SSO buffer. And I guess we shouldn't introduce a temporary object when M is a glvalue.

[jensmaurer]

@cor3ntin , please explain why your example doesn't satisfy the rules of a "core constant expression". The rationale you provided so far is insufficient, as explained by @frederick-vs-ja .

[cor3ntin]

@jensmaurer @frederick-vs-ja You are right, it is a core constant expression but not a constant expression.

We should still introduce a temporary for M (if it's not a glvalue), and specify its lifetime, same thing for data().

• The pointer returned by data() needs to be valid when reading data()[N]. In particular "D[i] shall be an integral constant expression" can only be true if D points to something within its lifetime, which in the example above depends on establishing the lifetime of M.
• We should avoid evaluating M more than once, (for example, evaluating it once for size() and once for data() would be less than ideal
• Destructors for M should be run (when M is a temporary) and we should enforce no memory leaks like we do in other places ([expr.const]p5.18) - important if M is a temporary string, for example

I'm not sure what the correct terminology is but we need some way to establish that the production of the message happens in a single evaluation context and the lifetime of M when M is a temporary is tied to that context.

[jensmaurer]

Why? How can you observe whether M.data()[i] evaluates "M" afresh for each "i" or not? It's a constant expression, after all.

[cor3ntin]

So you are saying the current wording allows an implementation to behave "as-if" M.data()[i] is executed in a loop, and that is currently not observable?

I guess that's somewhat possible (even if we really don't want that as an implementation strategy).
There might a point where that might stop being reasonable are side effects in constant expressions might become a possibility though (cplusplus/papers#1445)

[jensmaurer]

So you are saying the current wording allows an implementation to behave "as-if" M.data()[i] is executed in a loop

Yes.

and that is currently not observable?

Yes. (Counterexamples welcome.)

There might a point where that might stop being reasonable are side effects in constant expressions might become a possibility though

We can reconsider once we get there.