Which version of C++ should we try to support for constexpr?

[wusatosi]

This will impact what kind of standard libraries we have access to.

[camio]

It depends on how much of an implementation burden it would be to support older C++ standards. There's a case-by-case tradeoff between how many people can use this library and how much work it is to support older compilers.

[JeffGarland]

It depends on how much of an implementation burden it would be to support older C++ standards.

With where Beman is w.r.t. things we're doing I think c++17 would is turning out to be the sort of minimum level we can support. We'll let Boost do the legacy support.

There's a case-by-case tradeoff between how many people can use this library

So if we're to support older stuff so more can use it that means use it except for the constexpr capability. Boost takes the approach of defining a macro so they can remove constexpr from signatures and tests on older compilers. It's no fun and the code is ugly. This is my point above, but I'd go further and say the default should be to not bother working around earlier version unless there's a request from someone. And my response if it were my code would be PR's accepted.

None of this should be interpreted as user hostile -- rather it's author friendly and saves time from implementing things no one actually wants.

[wusatosi]

Current library version has a minimal version of C++ 20.

[wusatosi]

I can lower major version for non-constexpr features to C++17.
I haven't tried applying constexpr yet.

[wusatosi]

Looks like constexpr might need to stay at C++20.

Is there a constexpr costruct_at replacement for C++17? Looks like placement new operator is not constexpr.
This is one of the road block of constexpr-fying C++17...

[wusatosi]

See #22 for c++ 17 non-constexpr support