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

[ostream.inserters] vs [istream::extractors] and [alg.any_of] vs [alg.nth.element] #911

Closed
cubbimew opened this issue Aug 30, 2016 · 2 comments

Comments

@cubbimew
Copy link
Contributor

Is there any significance in the choice made between dots and colons in section names and also between representing underscores as-is and replacing them with dots? And does it make sense to come up with a consistent system, going forward? (I think too many external resources use the names as anchors to consider changing the existing ones)

grep tells me there are 38 section names with the :: (from [ios::failure] to [string::op>=]) and 1763 section names with dots, with no pattern to the colons other than clustering: it seems that colons shouldn't be used going forward.

Same for section names that use underscores directly (85 hits) vs the ones that replace each underscore with a dot (can't count with grep, examples include [memory.resource.monotonic.buffer] or [string.view]) -- this is less clear.

@tkoeppe
Copy link
Contributor

tkoeppe commented Aug 30, 2016

All this is wildly inconsistent. But I doubt we'll ever change any of the existing stable names. As far as new sections are concerned, I believe the working groups are aware of the need to pay attention to the stable section naming.

Do you expect any action to come from this issue?

@jwakely
Copy link
Member

jwakely commented Aug 30, 2016

it seems that colons shouldn't be used going forward.

Colons haven't been used in any new names for nearly two decades AFAIK. The C++98 names are ugly, but we're not doing that now.

use underscores directly (85 hits) vs the ones that replace each underscore with a dot

This is covered by issue #794.

@jwakely jwakely closed this as completed Aug 30, 2016
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

3 participants