Constexpr Everything Part 1: Constants #14487

I do this by hand, so make sure to report those whom I didn't see.

Could you add some rationale as to why this is necessary? Code style changes need to significantly improve the developer experience and avoid serious programming bugs. I do not see how this change does either of those things, so NACK

Concept Ack -- making these constexpr allows us to add more static_asserts (and similar things) about relationships between constants.

@JeremyRubin We can already use static_assert(…):s on the integer constants – we don't need constexpr for that :-)

[cling]$ const int i = 0;
[cling]$ static_assert(i == 0, "");
[cling]$ int j = 0;
[cling]$ static_assert(j == 0, "");
error: static_assert expression is not an integral constant expression

@practicalswift I think that is compiler dependent?

In any case, you also want to have relations be defined (e.g., constexpr functions).

@JeremyRubin

Actually I think it follows directly from the C++11 standard that we can use static_assert(…):s on integer constants also in the absence of constexpr specifier:

The syntax is ...

static_assert(bool_constexpr, message)

... where bool_constexpr is contextually converted constant expression of type bool.

What is a "contextually converted constant expression of type bool"?

A constant expression is a literal constant expression, a reference constant expression, or an address constant expression.

A converted constant expression of type T is an expression implicitly converted to type T, where the converted expression is a constant expression, and the implicit conversion sequence contains only:

• constexpr user-defined conversions (so a class can be used where integral type is expected)
• lvalue-to-rvalue conversions
• integral promotions
• non-narrowing integral conversions
• And if any reference binding takes place, it is direct binding (not one that constructs a temporary object)

A contextually converted constant expression of type bool is an expression, contextually converted to bool, where the converted expression is a constant expression and the conversion sequence contains only the conversions above. Such expressions can be used in noexcept specifications and static_assert declarations.

The text above is taken from cppreference.

FWIW, I tried compiling ...

const int i = 0;
static_assert(i == 0, "");

... in pedantic C++11 mode using clang, gcc, icc and MSVC. They all gladly accepted :-)

@DesWurstes can you fix up the whitespace issues (and squash your fixup commits) so the tests will run

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #14733 (P2P: Allow peer timeout to be configurable and speed up very slow test. by zallarak)
• #14605 (Return of the Banman by dongcarl)
• #14046 (net: Refactor message parsing (CNetMessage), adds flexibility by jonasschnelli)
• #14035 (Utxoscriptindex by mgrychow)
• #13972 (Remove 16 bits from versionbits signalling system by btcdrak)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

I understand that it is controversial to constexpr the constants as it's not a part of the code style. Should I open a separate Pull Request that replaces constexprs with consts?

@DesWurstes AFAIK there are no problems with constexpr from a code style perspective: I would say that we prefer contexpr:s for constants in new code. Have you gotten any contradicting information? :-)

Regarding this PR I think any objections would be based on the code churn vs benefit trade-off.

I would say that we prefer contexpr:s for constants in new code

There's no mention of that. Before doing this, the developer notes need to be updated when to use constexpr and when const, along with the rationale. Not everyone is sufficiently up to date with C++11 to know this—is it always better to use constexpr? and if so, why does const still exist?

The word constexpr doesn't appear in doc/developer-notes.md.

Edit: and yes, code churn is the big factor here. We don't generally update the entire code base for changes in the code guidelines, this is only applied to new code, and only rarely—say, as cleanup before a release, done globally.

There hasn't been a follow-up to address the feedback (Document the new guideline in the developer notes), so I am closing this for now. Please let me know when you start working on this again, so I can reopen.