Update to C++14.

[1uc]

For 3.0.0 should C++14 be the new minimum supported version? Please list features you'd like to use, or explain why this would be disruptive.

[1uc]

It feels like C++14 is very widely supported now. (Needs to be checked.) Therefore, it may make sense. On the other hand I'm not convinced that HighFive gains much. The one convincing argument I've heard is std::enable_if_t. Personally, I feel that doesn't improve anything for users, and of devs its a cosmetic change.

[alkino]

I would prefer C++17 to have if constexpr and some other features.

[1uc]

Yes, C++17 would add features we could use.

Unfortunately,
https://github.com/BlueBrain/libsonata/blob/0577eb5142e65363087facb9dc6c12dfd2ae49f2/CMakeLists.txt#L58
https://github.com/BlueBrain/MorphIO/blob/6038b3be8ad277a2b4c4ebb441b48d8262ee031a/CMakeLists.txt#L39

so I don't think we're able to make this change. Moreover, I'm not convinced C++17 is sufficiently mainstream yet; and C++23 would allow us to write a completely different library: std::mdspan, concepts, modules, structured binding, etc. Therefore, I'm leaning towards leaving HighFive at C++14 and let someone build H5++23 for C++23 onwards.

[VictorEijkhout]

I was just going to remark that you have examples with vector of vectors and that mdspan is decidedly more modern, certainly for the sort of users that would use hdf5.

[1uc]

C++14 added [deprecated] which is portable and can be used for using statements. This allows the following:

namespace deprecated {
class Old{
 // ...
};
}

using Old [deprecated("soon gone")] = deprecated::Old;

foo(const deprecated::Old& old);

Directly deprecating Old has the effect that HighFive itself will using the deprecated feature and generate warnings because of this.

[1uc]

We might use unique_ptr in the future. Hence, C++14 seems sensible.