Should we move to c++20 standard ?

[VincentRouvreau]

According to c++ 20 compiler support, it seems that almost all C++20 features are ready for GCC, Clang and MSVC with versions that can be easily installed on a system.

Moreover, if we move with nanobind and scikit-build-core, it also seems that c++20 is well supported. I remember that after #1196 the build requirements will be:

Python >= 3.9, NumPy >= 1.15.0, scikit-build-core >= 0.4.3 and nanobind>= 1.3.2 to compile the GUDHI Python module.

And finally, I can see no real constraint to go with MSVC 2019

If you have any argument for not to go this way, please give some examples or just 👍 if you want this feature.

Pros are:

• We could use c++20 mdspan instead of our own implementation
• we could remove Boost::filesystem dependency (on Cech benchmark)

[mglisse]

https://gcc.gnu.org/projects/cxx-status.html#cxx20

GCC has experimental support for the previous revision of the C++ standard, which was published in 2020.

(in particular this means that the ABI for C++20 features changes between gcc-14 and gcc-15)

gcc does not have mdspan yet according to the list you link to, so it wouldn't help with that.

I'd like to see a stronger motivation than mild clean-ups for this move, at least until the main compilers advertise a less experimental status.

[hschreiber]

* We could use c++20 mdspan instead of our own implementation

std::mdspan is C++23, std::span is C++20.

I don't have a very strong opinion about this topic, with a little preference about moving to C++20. It is already 5 years old and it would give me a good opportunity to play with the new introduced tools like concept and std::ranges::[...] etc.