Provide C++20 module

Start by reading boost/program_options.hpp, the current Jamfile, and the CMake export configuration named in the proposal to map the public API and build entry points. Review how tests are organized before defining import-compilation coverage for GCC, Clang, and MSVC. Done means an opt-in module target builds and installs, preserves header-based use, exposes the public API, and is documented.

ITNOA

Abstract

This RFC proposes the introduction of a C++20 module interface (import boost.program_options;) for the Boost.Program_Options library. This addition will provide modern C++ developers with faster compile times, better translation unit isolation, and a cleaner transition path toward modern C++ standards, while fully maintaining backward compatibility with legacy header-based inclusion.

---

Motivation

As C++20 modules gain widespread compiler and build system support (CMake, B2, MSBuild), standardizing library interfaces into modules has become a key step in modernization.

Boost.Program_Options is a widely-used library, but its heavy header footprint can significantly impact compilation times in large projects. By introducing a native C++20 module interface, we can offer:

1. Drastically Improved Compile Times: Pre-compiled module interfaces (.ixx / .cppm) reduce parser overhead across translation units.
2. Elimination of Macro Pollution: Standard headers leak internal macros; C++20 modules export only what is explicitly declared in the interface.
3. Clean API Boundaries: Stronger encapsulation of the internal parser logic from the user-facing API.

---

Proposed Design & Usage

1. User-Facing API

Users should be able to consume the library using standard module import syntax:

// Modern C++20/C++23/C++26 entry point
import boost.program_options;
import std;

int main(int argc, char* argv[]) {
namespace po = boost::program_options;

po::options_description desc("Allowed options");
desc.add_options()
("help,h", "produce help message")
("compression", po::value<int>(), "set compression level");

po::variables_map vm;
po::store(po::parse_command_line(argc, argv, desc), vm);
po::notify(vm);

if (vm.count("help")) {
std::println("{}", desc); // Or std::cout in C++20
return 0;
}
}

2. Module Interface Definition (boost.program_options.cppm)

We propose exporting the public API via a primary module interface:

module;

// Global module fragment for legacy internal macro dependencies if any
#include <boost/program_options.hpp> 

export module boost.program_options;

export namespace boost::program_options {
// Export core classes and utilities
using boost::program_options::options_description;
using boost::program_options::variables_map;
using boost::program_options::value;
using boost::program_options::store;
using boost::program_options::parse_command_line;
using boost::program_options::notify;
// ... other public APIs
}

---

Backward Compatibility

This proposal is strictly additive:

• The traditional header-based approach (#include <boost/program_options.hpp>) will remain fully supported and unchanged.
• The module interface will act as a wrapper exporting the existing namespace symbols, ensuring no breaking changes to the underlying implementation.

---

Action Plan & Roadmap

To implement this change smoothly, we suggest the following tasks:

[ ] Define Module Interface: Create the primary module partition/interface (.cppm / .ixx) mapping out all public-facing classes and functions.
[ ] Build System Integration:

• Update Jamfile (B2) to support compiling and installing the C++20 module.
• Update CMake export configurations (BoostConfig.cmake) to expose the modern target Boost::program_options_modules (or similar).

[ ] Test Coverage: Add test cases checking standard compilation with import boost.program_options; under GCC, Clang, and MSVC.
[ ] Documentation: Update the Boost documentation to include a “Getting Started with C++20 Modules” section.

---

Drawbacks & Open Questions

• Tooling Support: While CMake 3.28+ and B2 have active support for C++20 modules, older legacy build setups may face challenges. Providing a clear opt-in flag (e.g., BOOST_PROGRAM_OPTIONS_BUILD_MODULES=ON) is highly recommended.
• Macro Exports: Any macros currently relied upon by users (if any) will not be exported via import. Users requiring those specific macros will still need to include the classic headers.