c++ - Which parts of the C++14 Standard Library could be and which parts will be made constexpr?

Question

With the new relaxed C++14 constexpr rules, compile-time programming becomes a lot more expressive. I wonder whether the Standard Library will also be upgraded to take advantage. In particular, std::initializer_list, std::pair, std::tuple, std::complex, std::bitset and std::array seem like prime candidates to be marked constexpr wholesale.

Questions:

• which parts of the Standard Library will now be marked constexpr?
• which other parts could be marked constexpr?
• e.g. why aren't the functions from <cmath> and <algorithm> marked constexpr?
• are there backwards compatibility reasons not to do so?

Answer 1

which parts of the Standard Library will now be marked constexpr?

From the draft that I've looked at for C++14, N3690, the following will be changed to constexpr thus far (In comparison with the C++11 standard)†:

• std::error_category's default constructor
• std::forward
• std::move
• std::move_if_noexcept
• All of std::pair's operator comparisons
• std::get for std::pair and std::tuple.
• std::make_tuple
• All of std::tuple's operator comparisons
• All of std::optional's operator comparisons
• All of std::optional's constructors (save for move)
• operator[] and size for std::bitset and other containers.
• All of std::complex's operator comparisons

† _{Since I did this manually, you can expect some errors :(}

For another possibly more correct list of constexpr additions you can check: N3469, N3470, and N3471

which other parts could be marked constexpr?

Most of the stuff that could be constexpr (std::numeric_limits evaluation, std::tuple and std::pair constructors, etc) were already marked as constexpr in the C++11 standard. There was a bug in which std::ratio's time points and other components weren't marked as constexpr but it was fixed in N3469.

Something that would benefit from constexpr additions would be std::initializer_list, which didn't get any this time around (and I'm unsure if there have been any proposals to allow it).

are there backwards compatibility reasons not to do so?

Since this is an extension, most stuff won't be broken since older code will still compile as-is and nothing is now ill-formed. However adding constexpr to older things that didn't have it could lead to some surprising results if you didn't expect it, such as the example provided here (Thanks TemplateRex)