Add modern API based on C++26 features

[soroshsabz]

ITNOA

There have been significant changes from C++03 to C++26 that fundamentally affect API design in C++.

Consequently, I propose designing a new API for program_options based on C++26 best practices.

Key modern C++ features we can leverage include:

• Modules: For faster build times and cleaner library exposure.
• Concepts: For improved template metaprogramming and clearer constraints.
• Contracts: For more robust code and runtime/compile-time assertions.
• std::optional: For a more declarative API when handling optional values.
• std::variant & std::any: For type-safe, flexible option storage.
• Structured Bindings: For a cleaner, more intuitive API when unpacking values.
• std::span & std::string_view: For zero-copy, high-performance string and array views.
• std::expected: For modern, expressive error handling instead of exceptions or return codes.
• Compile-Time Reflection: For smarter, automatic type inference and a significantly cleaner API footprint.

To achieve this, we should redesign the public API in a C++26-native way and modernize the underlying codebase.

To make this actionable, I suggest the following roadmap:

• Design the V2 API: Create a new, modern API namespace/module separate from the legacy API to maintain backward compatibility.
• Modernize the Codebase: Migrate the internal implementation details to C++26.
• Expose the C++26 API: Provide the new public-facing API for modern users.

[vprus]

Thanks for your proposal.

As mentioned in README, I consider the library to be essentially done. The primary goal is stability. I don't think the rewriting in C++26 and requiring C++26 compiler fits that goal, and redesigning API even less fits this goal.

Of course, if you think such a V2 API would be of interest to C++ users, I don't want to discourage you from designing it, just it would have to be a separate project.

[soroshsabz]

@vprus

Thank you for the quick response and for clarifying the priorities around stability and maintenance.

I completely understand and respect that stability is the primary objective for the current codebase. However, I’d like to share why keeping a V2 inside Boost.Program_Options rather than spinning it off into an external library could benefit both Boost and its users:

1. Boost Precedent for V2 APIs:
   Boost has a strong history of modernizing core libraries in-tree while preserving legacy stability. Libraries like Boost.Filesystem (v3/v4), Boost.Process (v1/v2), and Boost.Geometry evolved within Boost without breaking legacy users. A boost::program_options::v2 (or inline namespace) approach allows the existing API to remain the default for older standards (C++03/11), while offering modern idioms to newer toolchains.

2. Zero Impact on Existing Users:
   The proposed V2 would not rewrite or alter the existing implementation. It would be strictly additive, opt-in, and conditionally compiled based on compiler standard flags (__cplusplus), ensuring 100% ABI/API stability for existing codebases.

3. Keeping Boost at the Forefront:
   Boost has historically led the C++ community in establishing modern best practices. Having an official, modern CLI parsing interface under the familiar Boost umbrella ensures developers don’t have to look outside the ecosystem for modern language features.

If maintenance bandwidth is the main concern, I would be more than happy to do the design and implementation work under an experimental branch or as an opt-in sub-namespace without disrupting the existing codebase.

Would you be open to an experimental, opt-in V2 interface under these constraints, or would you still prefer this to go through a formal Boost incubator / review process as a separate candidate library first?

[vprus]

I am afraid I'm still skeptical here. This is a command-line parser. It's not a performance bottleneck in any app. Its API is not a cognitive bottleneck in any app either. AI can use this API, without human oversight. Lastly, there's a pile of areas in Boost or C++ that are more interesting, closer to business logic, might still warrant human authorship, and need API improvement.

Therefore, it might be more reasonable if you prototype your API, present it on the mailing list, and gather opinions. It is possible that I'm wrong, and the new API will be a runaway hit. Alternatively, it might turn out that it's nicer, but does not justify the work to to fully implement, and importantly, the extra work imposed on users in the form of learning new API.