{{ message }}
[pairs.pair, variant.ctor, tuple.cnstr] Only functions can be "constexpr-suitable"#8807
Open
Quuxplusone wants to merge 1 commit intocplusplus:mainfrom
Open
[pairs.pair, variant.ctor, tuple.cnstr] Only functions can be "constexpr-suitable"#8807Quuxplusone wants to merge 1 commit intocplusplus:mainfrom
Quuxplusone wants to merge 1 commit intocplusplus:mainfrom
Conversation
…xpr-suitable" This starts by reverting commit 79aef51, and then un-teletypes the word `constexpr` in "is a `constexpr` function" in the last place it's currently teletyped (after cplusplus#6620, that is).
Member
Contributor
Author
@jwakely: Did you read the patch, though? It doesn't feel like you read the patch. |
Member
|
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. |
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

[variant.ctor]/6 currently has—
First glance:
constexprshould not be in teletype font. We don't mean that this constructor isconstexpr; 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_0can 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 theconstexprkeyword).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, whilestd::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
constexprin "is aconstexprfunction." (That was the last place it's teletyped anymore, after #6620.)