[pairs.pair, variant.ctor, tuple.cnstr] Only functions can be "constexpr-suitable"

[Quuxplusone]

[variant.ctor]/6 currently has—

constexpr variant() noexcept(see below);

Remarks: This function is constexpr if and only if the value-initialization of the alternative type T_0 would be constexpr-suitable.

First glance: constexpr should not be in teletype font. We don't mean that this constructor is constexpr; we mean that this constructor is a constexpr function ([dcl.constexpr]/2).

Second glance: The only way for a function to be anything but constexpr-suitable is for it to be a coroutine. I don't think the value-initialization of T_0 can be a coroutine. Therefore the whole "if and only if" predicate can be eliminated. Which leaves only "This function is constexpr," which is obvious from the declaration (in that it uses the constexpr keyword).

Third glance: Actually it is a category error to talk about an "initialization" being "constexpr-suitable." A function (i.e. an entity) can be constexpr-suitable; it is not meaningful to talk about an initialization (nor an expression) being constexpr-suitable. So even if the sentence weren't redundant it would still fail to "type-check."

My initial suggestion: The function is already declared constexpr. Strike the Remarks.

However, looking at the history, it looks like this wording got into its current state as a result of commit 79aef519 — which was just wrong — but the previous wording was clearly there to deal with the longstanding open question of how LWG is supposed to specify that a particular function call is "constexpr-friendly." We want to mandate that std::variant<std::string> v; must be constexpr-friendly, while std::variant<std::regex> v; is not (as of C++26) constexpr-friendly. To completely strike these sentences would probably be worse than the status quo, in that department.

Therefore this proposed change starts by merely reverting commit 79aef51 to get rid of the incorrect use of "constexpr-suitable," and then additionally un-teletypes the word constexpr in "is a constexpr function." (That was the last place it's teletyped anymore, after #6620.)

[jwakely]

Isn't this another case of LWG2833?

Once again, completely removing this kind of "this is usable in constexpr when ..." wording because it's not perfect will get an over my dead body objection. We should fix it, not remove it. Until it's fixed, it's better to keep it.

[Quuxplusone]

Once again, completely removing this kind of "this is usable in constexpr when ..." wording because it's not perfect will get an over my dead body objection. We should fix it, not remove it. Until it's fixed, it's better to keep it.

@jwakely: Did you read the patch, though? It doesn't feel like you read the patch.

[jwakely]

I didn't, sorry, I had a kneejerk reaction to "strike the Remarks" and flipped the table. This doesn't feel editorial, but then neither was using the new term here, I guess. Reopening.

[frederick-vs-ja]

I'm not sure whether we want to temporarily fix these paragraphs in this way. In any case, these need to be fixed in LWG2833 again.

BTW, perhaps we should reword these with "Constant When:" (which should be in the resolution of LWG2833).