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
Comments
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:
Was that not right? |
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)). |
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 |
@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? |
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. |
@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. |
Oh, I think we already fixed this as part of b77c526. |
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 accompanyingenable_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.
The text was updated successfully, but these errors were encountered: