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

Consistency for template parameter names in standard library #3642

Closed
frederick-vs-ja opened this issue Jan 20, 2020 · 1 comment · Fixed by #3855
Closed

Consistency for template parameter names in standard library #3642

frederick-vs-ja opened this issue Jan 20, 2020 · 1 comment · Fixed by #3855
Assignees

Comments

@frederick-vs-ja
Copy link
Contributor

In the current standard draft (N4849):

Almost all type template parameter names used for description of the standard library are of PascalCase, except for

  • charT and traits representing character type and its related character/regular expression traits type, used by many components
  • internT, externT and stateT used by std::codecvt and std::codecvt_byname
  • Byte_alloc and Wide_alloc used by std::wstring_convert which is deprecated since C++17

Should we make them all PascalCase, i.e. replace them with CharT, Traits, InternT, ExternT, StateT, ByteAlloc and WideAlloc respectively for consistency?

Non-type template parameter names used by components in <random> and <semaphore> are of snake_case (or a single word of all lowercase), while others are of PascalCase (or a single word whose first letter is of uppercase).

Should we also make them all PascalCase? (#3616)

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Jan 23, 2020
@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Feb 10, 2020
@jensmaurer
Copy link
Member

Editorial meeting: For charT and traits, it's churn for no real gain. Fix the third bullet.
Leave everything else alone.

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