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.

Sign up for GitHub

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

Jump to bottom

[check] Add check for "explicit constexpr" in the library #5948

Merged
merged 2 commits into from Nov 15, 2022
Merged

[check] Add check for "explicit constexpr" in the library #5948

merged 2 commits into from Nov 15, 2022

Conversation

CaseyCarter
Copy link
Contributor

Per our style guide, constexpr should precede explicit in declarations. Nevertheless, the persnickety explicit constexpr seems to frequently sneak into the library wording.

@CaseyCarter CaseyCarter mentioned this pull request Nov 12, 2022
Merged
@Mick235711
Copy link
Contributor

Mick235711 commented Nov 12, 2022 •
edited

We might also consider enforcing:

  • static constexpr (412 occurrence) instead of constexpr static (7 occurrence)
  • either static inline (2) or inline static (3)
  • either extern constexpr (1) or constexpr extern (1)

(Just from a grep search on "word1 word2", highly likely to not find some hidden positives like the one in [depr.static.constexpr], but the checking script is just doing grep anyway)

@CaseyCarter
[check] Add checks for "explicit constexpr" and "constexpr static" in…
de695b2 
… the library

Per our style guide, `constexpr` should precede `explicit` and `static` should precede `constexpr` in declarations. Nevertheless, the persnickety `explicit constexpr` seems to frequently sneak into the library wording.
@CaseyCarter
[vector.bool.pspc] Replace constexpr static with static constexpr
8b64db3 
As preferred by our style guide.
@CaseyCarter
Copy link
Contributor Author

We might also consider enforcing:

  • static constexpr (412 occurrence) instead of constexpr static (7 occurrence)
  • either static inline (2) or inline static (3)
  • either extern constexpr (1) or constexpr extern (1)

Most of the inconsistent orderings you found are in examples in core wording, which is fine and intended. Only in the library wording are we concerned about following a consistent order of specifiers in our decl-specifier-seqs (See https://github.com/cplusplus/draft/wiki/Specification-Style-Guidelines).

I added a checker for static constexpr, which occurs tons in the library and once in the wrong order vector<bool>. I haven't bothered for static inline and extern constexpr which don't appear in the library wording at all.

@Mick235711
Copy link
Contributor

Thanks for the clarification! That make sense for me.

@tkoeppe
Copy link
Contributor

tkoeppe commented Nov 15, 2022

Thanks, Casey!

@tkoeppe tkoeppe merged commit 608c152 into cplusplus:main Nov 15, 2022
@CaseyCarter CaseyCarter deleted the check branch November 15, 2022 06:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jwakely jwakely jwakely approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@CaseyCarter @Mick235711 @tkoeppe @jwakely