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]/1 Incorrect reference to [temp.constr.decl]? #2944

Closed
RazvanAM opened this issue Jun 27, 2019 · 4 comments · Fixed by #2947
Closed

[expr.prim.req]/1 Incorrect reference to [temp.constr.decl]? #2944

RazvanAM opened this issue Jun 27, 2019 · 4 comments · Fixed by #2947
Assignees
@jensmaurer

Comments

@RazvanAM
Copy link

[expr.prim.req]/1

A nested-requirement can be used to specify additional constraints in terms of local parameters. The constraint-expression shall be satisfied ([temp.constr.decl]) by the substituted template arguments, if any. Substitution of template arguments into a nested-requirement does not result in substitution into the constraint-expression other than as specified in [temp.constr.decl]. [...]

I tracked the highlighted sentence to this commit (cplusplus/concepts-ts@52b22de).

Does the highlighted sentence mean that in the case of a requires expression such as:
requires { requires A<T>::val && B<T>::val; };
if A<T>::val evaluates to false then the template argument that corresponds to T is not substituted into B<T> (this would be helpful if B<T>::val would make the program ill-formed)? If so, then why is the reference to [temp.constr.decl]? I checked the contents of [temp.constr.decl] back when the commit was made, but I still cannot find a reason for the reference to be to that section.

I think a more appropriate reference could be to [temp.constr.op], which states that some constraints may remain unchecked.

Thank you.
@jensmaurer
Copy link
Member

Referring to [temp.constr.constr] seems to be most appropriate.

@jensmaurer jensmaurer self-assigned this Jun 28, 2019
@jensmaurer jensmaurer mentioned this issue Jun 28, 2019
Merged
@RazvanAM
Copy link
Author

I re-read the version of "constraints.tex" from when Richard Smith's commit was made (https://github.com/cplusplus/concepts-ts/blob/52b22de6edac608b72244fe1fdee4188a9c40f11/src/constraints.tex). I saw that back then the [temp.constr.decl] section contained the following paragraph:

A declaration's associated constraints are satisfied by a set of template
arguments if and only if its normalized associated constraints are satisfied
by those arguments.

This may be the reason why [temp.constr.decl] was referenced (in both sentences of [expr.prim.req]/1). And this may be relevant, as I think that the standard, in its current version, does not state when a constraint-expression is satisfied. It only states when a constraint is satisfied, but a constraint-expression first needs to be normalized in order to become a constraint.

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Jun 28, 2019
@jensmaurer
Copy link
Member

Well, it's certainly odd to have two cross-references to the same target within the same paragraph.

@RazvanAM
Copy link
Author

RazvanAM commented Jul 3, 2019 •
edited

This has been on my mind for a while. I keep trying to figure out why the references would be to [temp.constr.decl] at the time the commit was made.

The explanation that I can come up with is that [temp.constr.decl] was the section that made the link between constraint-expressions and constraints. This is because:

  • it described what the associated constraints of a declaration are (some of them being derived from requires-clauses made up of constraint-expressions)

  • it described when the associated constraints of a declaration are satisfied ([expr.prim.req]/1 uses the keyword satisfied)

  • it described the normalization process.

I think other sections were concerned only with constraints. @zygoloid, could you please confirm that this is the reasoning behind the initial references? Thank you very much!

@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Jul 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jensmaurer jensmaurer

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[expr.prim.req] Fix cross-reference for substituting into constraints. jensmaurer/draft
2 participants
@RazvanAM @jensmaurer