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

[lib] always use sub-namespace in itemdecls #2512

Open
zygoloid opened this issue Nov 26, 2018 · 1 comment
Open

[lib] always use sub-namespace in itemdecls #2512

zygoloid opened this issue Nov 26, 2018 · 1 comment
Assignees
Labels
big An issue causing a large set of changes, scattered across most of the text.

Comments

@zygoloid
Copy link
Member

For declarations in sub-namespaces, particularly within std::ranges, our itemdecls are often very unclear about which declaration they're referring to. For example, the only clue that the advance described in [iterator.operations] is in a different namespace from the advance described in [range.iterator.operations.advance] is the subclause name and how it's cross-referenced from the synopsis. That's not good enough.

We should consistently use a ranges:: prefix on the declarator-id for entities in namespace std::ranges (and likewise for other sub-namespaces of std).

@zygoloid zygoloid added the after-motions Pull request is to be applied after the pending edits from WG21 straw polls have been applied. label Nov 26, 2018
@jensmaurer jensmaurer added big An issue causing a large set of changes, scattered across most of the text. and removed after-motions Pull request is to be applied after the pending edits from WG21 straw polls have been applied. labels Nov 26, 2018
@jensmaurer jensmaurer self-assigned this Dec 21, 2018
@jensmaurer jensmaurer changed the title always use sub-namespace in itemdecls [lib] always use sub-namespace in itemdecls Jan 25, 2019
@JohelEGP
Copy link
Contributor

Should apply to some algorithms in utilities.tex within ranges::, like uninitialized_copy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big An issue causing a large set of changes, scattered across most of the text.
Projects
None yet
Development

No branches or pull requests

3 participants