When plan to migrate C++20 and above?

[soroshsabz]

ITNOA

Hi all,

I think C++20 and above introduces many useful features, so my question is, when you plan to migrate to C++20 or C++26?

some useful features are

• Modules (for better performance and library exposure)
• Concepts (for better meta programming)
• Contracts (for robust coding)
• std::optionals (for more declarative options)
• std::variants (same as above)
• std::any (same as above)
• structured binding (for better API)
• std::span (for better performance)
• std::string_view (for better performance)
• std::expected (for better API)
• compile time reflection (for more smarter inference and also cleaner API)

thanks

[phlptp]

It is an an interesting discussion. I think C++26 would be a while, but thinking about whether setting the minimum compiler support to C++17 might be worthwhile for version 3.0. @henryiii would have to weigh in, but I think it is at least worth considering. I know some code using it that needs to support C++17 for a few more years yet, so moving beyond that would require supporting two version releases.

[soroshsabz]

Thanks for reply, I think migration to new design API (based on more modern C++) make some time, and C++26 must be final until migration was finished, So C++26 maybe be a good choice based on this consideration.

But, if you/we have some constraints about using only final C++ versions, I think C++20 introduce many useful features and some of those come to maturity in C++23. So, I think best choice is C++23 in this situation.

[henryiii]

Modules are still really early phase adoption, especially std. We do fully support more recent C++ versions; we just also support older versions. I'd like to support modules, for example, but we can do that without dropping support for older versions or even newer versions without modules. We support things like using std::optional already.

I could see a redesign built on top of refection in the future, though. That could be a truly new interface. Otherwise, I don't think anything other than concepts would be that important. And std::string_view for performance, but we aren't performance limited.

I think we could go to C++14+ pretty much any time, it's just annoying that we have 11 in our name. Catch2 moved to C++14+, for example. I think C++17+ would be acceptable for a 3.0 version, but it might still be a little early - you have to drop support for macOS 10.13 or so targeting C++17, and some codebases (like older versions of Python) still target 10.9. But that's so close to going away that I think 17+ would be fine.

[henryiii]

I forgot std::expected, that would almost be worth a redesign. But it would sadly also change all user code.

[soroshsabz]

I forgot std::expected, that would almost be worth a redesign. But it would sadly also change all user code.

But that is very nice :)

[soroshsabz]

maybe you can change project name for next major version (for example ModernCLI :D)

[soroshsabz]

maybe we can have another approach, you can create all new public client API in C++23/26 (exist in new header/module files and new namespace) that rely on current code coexist with the current public client API, so you can save backward compatibility of library, and provide more modern API (cleaner and clever) with less maintenance cost (in backward compatibility scenario).

[phlptp]

It is kind of an interesting idea to rework the interface for C++26, it would be a long time before we could fully move over to that, but an interesting concept. Most of the code I work with is just starting to migrate to C++20, so another 6 years before we could fully migrate to C++26, but the idea is kind of intriguing.