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.

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

[sequence.reqmts] uses atypical and unclear wording for Cpp17 requirements and swappable conditions #5627

Closed
Dani-Hub opened this issue Jul 17, 2022 · 5 comments · Fixed by #5978

Comments

@Dani-Hub
Copy link
Member

During the submission process of LWG 3742 I realized that the suggested wording violates our current wording style in the following aspects:

  • For the Cpp17MoveConstructible and Cpp17MoveAssignable we should better use the form "T meets the Cpp17XX requirements" instead of "T is Cpp17XX"
  • Instead of saying that "T is swappable" we should say that "lvalues of type T are swappable"

The plain reason why we didn't decide for the more appropriate wording forms as part of this LWG issue was caused by the observation that the current local wording style used in subclause [sequence.reqmts] follows the same unusual style with the agreement that I would open an editorial issue to take care of this problem.

To be more specific, for example for the specification of insert_range we currently say:

Preconditions: T is Cpp17EmplaceConstructible into X from *ranges::begin(rg). For vector and
deque, T is also Cpp17MoveInsertable into X, Cpp17MoveConstructible, Cpp17MoveAssignable, and
swappable (16.4.4.3).

According to the preferred wording forms this should better say something like this:

Preconditions: T is Cpp17EmplaceConstructible into X from *ranges::begin(rg). For vector and
deque, T is also Cpp17MoveInsertable into X, T meets the Cpp17MoveConstructible and
Cpp17MoveAssignable requirements, and lvalues of type T are swappable (16.4.4.3).

I would like to get feedback whether such a rephrasing is possible as part of editorial work and to which extend, otherwise I would open a separate LWG issue to realize such wording changes. Of-course I'm also willing to make a corresponding editorial PULL request once we have agreement that such a change is editorially appropriate.

@jwakely
Copy link
Member

jwakely commented Jul 17, 2022

Such changes seem editorial to me. The intended meaning is clear, we're just not using the terminology correctly in the current wording.

@Dani-Hub
Copy link
Member Author

Such changes seem editorial to me. The intended meaning is clear, we're just not using the terminology correctly in the current wording.

Thanks, I'm working now at this suggestion.

Dani-Hub added a commit to Dani-Hub/draft that referenced this issue Oct 2, 2022
@Dani-Hub
Copy link
Member Author

Dani-Hub commented Oct 2, 2022

A PULL request has been provided, I'm kindly asking for a review.

@Dani-Hub
Copy link
Member Author

I have now provided a paper D2696R0, which contains wording that would solve this issue by a different means.

@Dani-Hub
Copy link
Member Author

Dani-Hub commented Nov 5, 2022

The paper has been published now: P2696R0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants