Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[expr.prim.req] Fix uses of 'unevaluated operand' #4832

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[expr.prim.req] Fix uses of 'unevaluated operand' #4832

wants to merge 1 commit into from

Conversation

jensmaurer
Copy link
Member

Fixes #4830

zygoloid
zygoloid reviewed Sep 9, 2021
View reviewed changes
Copy link
Member

@zygoloid zygoloid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally this looks good to me, but I have one concern:

I wonder if there are any complications here that would suggest we treat nested-requirements as unevaluated operands. I ask because we do treat the constraint-logical-or-expression of a requires-clause as an unevaluated operand, and it might make sense to be consistent. But I'm not sure how to square that with the disallowance of a requires-expression parameter appearing in a potentially-evaluated context.

Maybe we need CWG to take a look. It seems like we're overloading "unevaluated operand" to mean two different things here, and a nested requirement is unevaluated in only one of the two senses.

JohelEGP
JohelEGP suggested changes Sep 9, 2021
View reviewed changes
source/expressions.tex Outdated Show resolved Hide resolved
source/expressions.tex Outdated Show resolved Hide resolved
@jensmaurer
Copy link
Member Author

@zygoloid: Well, as it stands with my rewrite, the constraint-expression of a nested-requirement is NOT an unevaluated operand. Which allows us to talk about "potentially evaluated". I'm unsure what we want here.

Is there a minor fix that we could apply so that my patch can go forward, and we punt the rest to CWG?

@tkoeppe tkoeppe added the cwg Issue must be reviewed by CWG. label Sep 25, 2021
@JohelEGP JohelEGP mentioned this pull request Sep 26, 2021
Closed
@zygoloid
Copy link
Member

I think we can fix the first part of #4830 editorially, since that seems to just be confusion between two similar terms:

[expr.prim.req.nested]p2: "A local parameter shall only appear as an unevaluated operand (7.2) within the constraint-expression. An expression naming a local parameter shall not be potentially evaluated."

However, given the larger issue here -- which seems core-ish to me -- I'm not sure that's the right approach. So perhaps we should punt the whole thing to core?

@wg21bot wg21bot added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Oct 24, 2021
@jensmaurer jensmaurer removed the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Nov 20, 2021
@jensmaurer jensmaurer mentioned this pull request Nov 20, 2021
Closed
@wg21bot wg21bot added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Jun 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@zygoloid zygoloid zygoloid left review comments

@JohelEGP JohelEGP JohelEGP requested changes

Assignees
No one assigned
Labels
cwg Issue must be reviewed by CWG. needs rebase The pull request needs a git rebase to resolve merge conflicts.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

[expr.prim.req.nested] misuse of term "unevaluated operand"
5 participants
@jensmaurer @zygoloid @JohelEGP @tkoeppe @wg21bot