Hi John, thanks for bringing up the topic of C++20 modules in the realm of Boost! Am 05.04.2022 um 13:58 schrieb John Maddock via Boost:
The title says it all really, but in more detail:
1) Is there any existing best practice we should follow yet?
WG21 SG15 is about to come up with a document on that. Until then, I've touched this in my Meeting 2019 talk on modules, "Modules - the beginner's guide" Boost should be pretty safe here in general.
2) Can we share code content effectively between headers and modules? And by modules I mean "proper" ones: we should be able to write "import boost.whatever;" rather than importing a header.
This is possible and there's more than one way to do that. Both require an additional so-called module interface unit that defines the interface of a module (at least one per library). Option 1 is to export the public names through exported using-declarations in the purview of the module. Option 2 is a kind of preprocessor gymnastics in the existing headers to declare public names as exported when compiled from within the module interface unit. I've done that in the popular {fmt} library which is a so-called 'dual-mode library' (a term coined by me to describe the capability of a library to be consumed as both a module and a traditional header)
3) What directory structure should we all be using for module definition files?
Module interface units are just sources that require a special invocation at compile time.
4) Do we have Boost.Build support yet?
None afaik.
5) What file extensions should we be using?
Compiler vary here (msvc: .ixx, gcc: .cpp, clang: .cppm). SG15 seems to slowly converge towards .ixx. At least this is what I see in the SG15 meetings.
6) I presume we would all use the boost.libraryname and boost.libraryname.sub_feature naming convention with boost.libraryname pulling in the whole library?
A perfect situation for bikeshedding...
7) Does anyone have a handle on the current state of std library modularization?
It is voted into the C++23 draft. Microsoft has an experimental implementation for ages, Stephan (STL) has this currently on his plate and is actively working on it. I expect this to see this Real Soon Now in msvc.
8) Is there demand for this?
I've tried to get a handle on a modularized Boost in the past year but its current implementation seems to be quite hostile towards modules.
And no doubt lots of other things I haven't thought of.
There are a few pitfalls and things to consider if you want to use existing code in the modules world. I point out some of them in my talks last year (NDC, CppCon, Meeting C++). The last one from Meeting C++ 2021, "A (Short) Tour of C++20 Modules" is the most comprehensive and polished one, slides can be found on the Meeting C++ website. I gave a company training on topic that last week because the developers there are considering switching over to modules and were asking about the way forward, considerations to be taken into account, the state of the ecosystem, and all of my experiences in our daily use of modules in our company codebase. Ciao Dani