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

From: John Maddock (jz.maddock_at_[hidden])
Date: 2022-04-05 16:50:20

>>
>> 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)
Excellent, so it can be done, that was exactly what I was thinking of.  
Do you have  any feel for whether this improves performance and/or gets 
much use?
>
>>
>> 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.
Sure, but it's helpful for folks to know where to find stuff, we could 
just put them under /src, but since they're completely orthogonal to 
regular source files I would tend to opt for a separate directory.
>>
>> 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...
>
Green please, they're always green ;)
>
>>
>> 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.
Good!
>
>>
>> 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.
>
Many thanks, John.