On Fri, Mar 3, 2023 at 8:04 AM Alexander Grund via Boost < boost@lists.boost.org> wrote:
But I don't understand why you are against it. After all, there is BOOST_CXX14_CONSTEXPR (BOOST_CXX17/20_CONSTEXPR are still missing - but I already offered that). So we have an expressive scheme BOOST_CXXnn_CONSTEXPR that is unambiguous and readable.
C++14 lifted some major constraints on what can be in a constexpr function compared to C++11. Most notably support for more than just a return statement. Being able to differentiate that is useful in practice.
For example, std::round in C++23 is constexpr
The CXXyy part in the Boost.Config macros refers to the language level support. While std::round is at library level. So a compiler supporting C++14 constexpr syntax might not have a std library where std::round is constexpr even if it claims C++23 support. So the better way here would be a more focused macro combining the language level of the constexpr feature and the library support of what that specific function is using.
Hence a possible BOOST_CXX23_CONSTEXPR is misleading: It doesn't refer to the language level anymore. And if you bind that to availability of constexpr std::round the next user may want to use it with another std:: function which is supposed to be constexpr in C++23 but due to a std library defect is not yet. Hence the distinction between library level and language level feature macros.
Please see: https://en.cppreference.com/w/cpp/feature_test for language level macros -- look for _cpp_constexpr. I believe you'll discover that every combination you're looking for going back to cxx 2011 is represented -- basically making a boost config macro extraneous. The standard copied this idea from boost.config btw and it's quite powerful for portable libraries. Note that I regret using the boost.config macro for date-time constexpr stuff, because at this point I'd like to make the library available in a stand-alone fashion like boost.math. Not depending on boost.config would be helpful in that endeavor.
However IIRC some C++ standard added support of (temporary) allocations in constexpr functions. That would be worth a dedicated feature macro as that change fits the idea described above.
w.r.t. non-standard allocation support, sure that would be an extension perhaps worthy of a boost macro, but also maybe just check the compiler locally in the library that wants to use that extension. Jeff