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

[JeffGarland]

The PR was merged, is this issue overcome by events? Also, with c++26 now at design freeze and Beman libraries shifting to c++29 as a target, I think we should start all libraries at c++20 unless it really can't make use of any c++20 facilities (rare I think for any of the libraries being discussed). We could do that here as well.

[wusatosi]

The PR was merged, is this issue overcome by events?

That was for the previous iteration of the implementation.

[JeffGarland]

Sure, but I still think this can just be closed. The library is marked as constexpr (without macros) and requires c++20 -- probably the only thing required to demonstrate actual constexpr support is writing tests that prove which parts can be constexpr for a given compiler and std lib. tldr: It doesn't seem like there's any clear action for this issue.

[wusatosi]

probably the only thing required to demonstrate actual constexpr support is writing tests that prove which parts can be constexpr for a given compiler and std lib

We have this.

The library is marked as constexpr (without macros) and requires c++20

This is fair, we probably won't be able to lower constexpr support to C++17.

[JeffGarland]

probably the only thing required to demonstrate actual constexpr support is writing tests that prove which parts can be constexpr for a given compiler and std lib

We have this.

Perfect, this should be closed -- I'm going to let you do that though :)

[wusatosi]

Closed as completed per discussion.