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

From: Chuanqi Xu (chuanqi.xcq_at_[hidden])
Date: 2024-12-18 02:23:13

> This seems like a good candidate for a GSOC project. It would shift the load of a number of disparate maintainers to a one, or a few people that could solely focus on getting it correct. Most of the groundwork for adaptation in Boost already exists thanks to Reuben so it shouldn't require a huge amount of discovery.
Yeah, it sounds really nice. Would you like to plan one? I feel anarshal is qualified to take the mentor's position. And I like to help if needed.
> Would have been nice if the `export` keyword was accepted and silently ignored
when outside of module.
Yes, but we have missed the train.
> but in the general case you'd have something like
>
> #ifdef BOOST_USE_MODULE_CORE
> import boost.core;
> #else
> #include <boost/core/this.hpp>
> #include <boost/core/that.hpp>
> #endif
>
> repeated for every library you #include things from.
Yes, exactly. And in fact, this pattern is relatively trivial. I wrote a tool to do such conversions (https://github.com/ChuanqiXu9/clang-modules-converter <https://github.com/ChuanqiXu9/clang-modules-converter >). This tool would only participate the process of rewriting so it won’t be put into boost’s ecosystem. People can also make their own tool since the problem in source level is trivial, simple and common actually.
> And the end user will have to do this too.
Maybe not for all. See the list of github links I sent. I believe in these links users can replace `#include` to import for boost simply. (I know what you’re saying. Just to say not all users need to do that.)
> I'm also not quite clear on how things will work on the CMake side.
To be honest, I don’t have an insight here. Our use experience was based on a modified bazel, not cmake. And also our code is in a monorepo in a closed world. It might be different in the open world.
I CCed the CMake dev for modules. I guess he is willing to help.
> Also, we're basically talking Clang-only here, right? GCC doesn't work and
MSVC... may or may not work?
From the discussion thread, I think we’re talking about standard C++20 modules. We’re not talking about any extension or compiler specific behaviors. So I believe what we plan to do here is fine. Even if some compilers are not able to make it now, I believe it will someday.
> 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.
My take away for boost guys is, when we make boost modular, we’d better to assume `import std;` is available. Or boost don’t need to care the case: let’s provide boost modules without std module.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Matt Borland <matt_at_[hidden]>
Send Time:2024 Dec. 17 (Tue.) 21:35
To:boost<boost_at_[hidden]>
Cc:Chuanqi<chuanqi.xcq_at_[hidden]>
Subject:Re: [boost] Interest for C++20 modules support of boost officially
> Boost has a special position in the C++’s ecosystem. The most simple and impressive answer I’ve heard for the question “when can we start to use modules” is, “when boost makes it”.
> 
This seems like a good candidate for a GSOC project. It would shift the load of a number of disparate maintainers to a one, or a few people that could solely focus on getting it correct. Most of the groundwork for adaptation in Boost already exists thanks to Reuben so it shouldn't require a huge amount of discovery.
Matt