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

Globally replace ambiguous use of "constraints" #1670

Closed
hubert-reinterpretcast opened this issue Jul 18, 2017 · 7 comments
Closed

Globally replace ambiguous use of "constraints" #1670

hubert-reinterpretcast opened this issue Jul 18, 2017 · 7 comments
Milestone
C++20 Concepts

Comments

@hubert-reinterpretcast
Copy link
Contributor

P0734R0 presumably defines "constraint" as a term of art.
The Working Draft prior to integrating P0734R0 already uses "constraint" with another meaning.

The use of "satisfied" is less of an issue since P0734R0 would only define it in relation to satisfying a constraint.
@jensmaurer
Copy link
Member

We use "constraint" in its English meaning quite a bit. Maybe use "template-constraint" for the P0734R0 meaning, similar to our artificial phrases odr-used and injected-class-name?

@hubert-reinterpretcast
Copy link
Contributor Author

"template-constraint" would work. Not sure how much discussion such a change would generate though.

@jensmaurer jensmaurer added this to the C++20 Concepts milestone Jul 18, 2017
@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Oct 19, 2017
@jensmaurer
Copy link
Member

Editorial meeting consensus: We have constraints on non-templates. "template-constraint" is probably not going to work. Try to use bare "constraint" only within 17.4 temp.constr, everywhere else we should ensure we never use bare "constraints", but "associated constraints" or similar.

@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Nov 7, 2017
@jensmaurer
Copy link
Member

A quick search shows that we use "constraint" all over the place to talk about restrictions established by the surrounding specification text, totally unrelated to concept-style constraints. We need a new plan.

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Feb 13, 2018
@zygoloid
Copy link
Member

Approach: replace "constraints" with "associated constraints" everywhere that is correct, then look again at what instances of "constraints" remain that refer to the Concepts notion of constraints and make more decisions.

@zygoloid zygoloid removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Mar 18, 2018
@tkoeppe
Copy link
Contributor

tkoeppe commented Jul 2, 2018

Is there still work pending for this issue?

@jensmaurer
Copy link
Member

We seem to use "associated constraint" or "atomic constraint" or "constraint-expression" pretty universally where we mean it. Please open a new issue with specific references if you find violations somewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
C++20 Concepts
Development

No branches or pull requests
4 participants
@zygoloid @hubert-reinterpretcast @tkoeppe @jensmaurer