Update to C++20? #107
Description
This would notably allow:
| Feature | Benefit |
|---|---|
std::u8string |
Clearer UTF-8 string semantics |
std::format |
dropping the dependency on fmt |
std::span<T> |
An alternative to const std::vector<T>& that avoids having to construct a vector if you've got another compatible sequence - not sure if this is a problem outside of test code |
<=> operators and default comparison operators |
Reduce code needed to define comparison operators |
| Ranges | Simplifies using std algorithms, I don't think there's anything major in libloot that would benefit from using the new functionality though |
std::string_view::starts_with(), std::string_view::ends_with() |
Trivially replace usage of a couple of Boost functions (still need the string algorithms library for many other uses) |
| Concepts | Better templates - not really significant for libloot, it doesn't define many templated types or functions |
There might also be some other stuff I've missed - modules is intentionally omitted due to poor support outside of MSVC.
Updating to C++20 may mean increasing the compiler version requirements. It looks like MSVC 2019 and GCC 13.1 should be enough. From a CI perspective, no changes would be needed:
- libloot and LOOT have used MSVC 2019 in CI since February 2022, shortly before GitHub removed its runners that provided MSVC 2017, so 2019 might already be required in practice.
- libloot and LOOT have used GCC 13 in CI since migrating from the Ubuntu 20.04 runners to 24.04 runners in January 2025. Before that it was using GCC 10.
There's not really a compelling reason that I've seen to update to C++20, but it is now 5 years old and the required compilers are at least just under 2 years old, so updating the build requirements doesn't seem unreasonable and there might be language-level improvements that lead to less obvious things like performance improvements.
That said, I did just flip the switch in CMake and immediately ran into compiler errors due to std::filesystem::path::u8string() now returning a std::u8string instead of a std::string, and astoundingly there doesn't seem to be an easy way (barring a pointer reinterpret cast) to convert a std::u8string to a std::string even though it should be trivial (I could understand it if the other way around required a UTF-8 validity check). That alone is enough for me to think it's not worth dealing with.