Re: Interest for C++20 modules support of boost officially

From: Daniela Engert (dani_at_[hidden])
Date: 2024-12-17 16:23:06

Am 17.12.2024 um 16:29 schrieb Peter Dimov via Boost:
> Chuanqi Xu wrote:
>>   For authors of libraries, after boost introduce modules, you only need to do 2
>> extra things:
>> - In headers, add a macro (assume its name as BOOST_MODULE_EXPORT,
>> which will be ‘export’ conditionally) to the entities that need to be exported.
> Would have been nice if the `export` keyword was accepted and silently ignored
> when outside of module.

Totally so!

Whoever is considering to introduce module support into some Boost 
library should be acutely aware of, and familiar with, the following 
sections in the C++ standard and its implications:

 Â  * http://eel.is/c++draft/module.reach#3
 Â  * http://eel.is/c++draft/module.reach%c2%a0%c2%a0%c2  in general

and in particular

 Â  * http://eel.is/c++draft/module.global.frag#3
 Â  * http://eel.is/c++draft/module.global.frag#4

This applies to all modules which are *not* leafs in the entire 
dependency tree and contain so-called global module fragments 
(http://eel.is/c++draft/module.global.frag) in user-facing TUs.

Some compilers do *not* implement GMF entity pruning correctly, or at 
all. This will lead to disappointed and/or frustrated users, or - even 
worse - to users who are misled to assume seeing correct module BMIs, 
while these are - in fact - incorrect. This was one the topics in my 
modules workshop this fall (hint: stay away from Clang at least up to 
18. Clang 19 *might* have improved in this regard). The recommended 
remedy is to avoid #includes of standard library headers at all and turn 
to import std; instead. But this is just the starting point.

Dani

-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5