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

views::stride in [ranges.syn] should not be marked freestanding #5733

Closed
ben-craig opened this issue Aug 16, 2022 · 7 comments
Closed

views::stride in [ranges.syn] should not be marked freestanding #5733

ben-craig opened this issue Aug 16, 2022 · 7 comments

Comments

@ben-craig
Copy link

P1642 (freestanding stuff) has a merge conflict / editing race condition with P1899 (stride_view). Both were added in the same plenary, and both wanted to modify ranges.syn. The drafting note in P1642 did not explicitly call out stride_view though, so views::stride probably shouldn't get the // freestanding comment. Note that only views::stride got an erroneous freestanding mark. stride_view and the accompanying enable_borrowed_range didn't get such a mark (which is the correct editorial decision).

From a design standpoint stride_view and friends are totally fine in freestanding, but we'll need a paper / NB comment to fix that at this point.

@tkoeppe
Copy link
Contributor

tkoeppe commented Aug 16, 2022

Could you perhaps send a pull request to remove erroneous annotations?

I had understood the wording of P1642 to mean that LWG had implicitly approved the pending changes:

The following papers are all in the LWG queue as of 2022-04-09:
...
[P1899 views::stride](http://wg21.link/P1899)
...
The above papers add facilities to <ranges>, <utility>, and <functional>. The wording in this revision will include those facilities implicitly

Was that not right?

@JohelEGP
Copy link
Contributor

Looks like an accident indeed: https://github.com/cplusplus/draft/pull/5640/files#diff-015716b0f124dba6acb7cdf24285de5d954d0958ca8abbb2ad82a015d1852a9eR445-R454.

P1899 was not part of the drafting notes (quoted by #5596 (comment)).

@frederick-vs-ja
Copy link
Contributor

frederick-vs-ja commented Aug 18, 2022

I guess we can keep the current working draft as-is now even if it's contradictory, as the working draft used to have long-standing noexcept mismatch that was eventually fixed via LWG issues.
IMO an LWG issue should be filed soon to make stride_view and its friends freestanding.

@tkoeppe
Copy link
Contributor

tkoeppe commented Aug 18, 2022

@ben-craig Could you please confirm that the sentence I quoted, "The wording in this revision will include those facilities implicitly", does not mean that those new features from the LWG queue have been approved to be freestanding?

@ben-craig
Copy link
Author

The merge conflicts that LWG approved are the ones mentioned in the drafting notes. The freestanding paper was reviewed and approved by LWG on July 2, and stride was approved on July 8. When reviewing freestanding, we only verified and explicitly approved of the things that were already LWG approved.

@tkoeppe
Copy link
Contributor

tkoeppe commented Aug 19, 2022

@ben-craig: thanks -- I think it was a misunderstanding on my part then. I thought that LWG had approved the wording "The wording in this revision will include those facilities implicitly" with the interpretation that those implicit inclusions are also approved.

@tkoeppe
Copy link
Contributor

tkoeppe commented Aug 19, 2022

Oh, I think we already fixed this as part of b77c526.

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

No branches or pull requests

4 participants