Re: So.... what are we going to do about modules?

From: Daniela Engert (dani_at_[hidden])
Date: 2022-04-05 13:09:38

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