Hi Boost Developers, I am Chuanqi Xu, the maintainer for modules & serialization in clang and also a fan of C++20 modules. The post itself was motivated by a discussion (https://cpplang.slack.com/archives/C27KZLB0X/p1734335425348809 <https://cpplang.slack.com/archives/C27KZLB0X/p1734335425348809 >). You don’t need to read it if you’re not interested. I’ll try to make the post itself self contained. The original story comes from a high quality experiment for C++20 modules in boost (https://anarthal.github.io/cppblog/modules2 <https://anarthal.github.io/cppblog/modules2 >). The blog reads pretty good to me. However, anarthal (the author) told me later that the process of supporting modules in boost got suspended since the authors (or the maintainers) don’t want it since no one is going to use them. And if I want it, I need to send a mail here. Then this is the beginning of the story. First of first, I want to emphasize that “no one is going to use them” is not true. We’ve already used C++20 modules at larger scale internally for roughly a year. For boost (and other third party libraries), we choose to wrap a module ourselves as a workaround (with some compiler extensions to ease the refacotoring, but we don’t like it. We still want standard behavior). We didn’t reach out since we feel boost will support C++20 modules later or sooner so we don’t need to do anything specially. (Maybe we were wrong. We didn’t understand the ecosystem enough). Until yesterday, I just knew that boost didn’t know such needs. Before I wrote this email, I wondered a lot of words to emphasize that our need are a good example and the users of closed source are important users too. But just now, I searched the use of boost in modules in GitHub. I just realized I can show it (the importance of C++20 modules support for boost) much easily with the open source world. I searched `boost path:*.cppm` in GitHub and got the following list: https://github.com/infiniflow/infinity/blob/fa922afd58c973a9a317d2c09ad8cea8... <https://github.com/infiniflow/infinity/blob/fa922afd58c973a9a317d2c09ad8cea8... > https://github.com/ossia/score/blob/0ce6f62a97651a1248a92b3e13ce6ede10341d1f... <https://github.com/ossia/score/blob/0ce6f62a97651a1248a92b3e13ce6ede10341d1f... > https://github.com/RichardLuo0/make-dot-cpp/blob/e2ef10fd43060a2b56fc8f87f14... <https://github.com/RichardLuo0/make-dot-cpp/blob/e2ef10fd43060a2b56fc8f87f14... > https://github.com/slaakko/cmajor-mod/blob/32e6eb8dc099b395fa751340de96f4781... <https://github.com/slaakko/cmajor-mod/blob/32e6eb8dc099b395fa751340de96f4781... > https://github.com/df-com/dragonfly/blob/9dfcbc1153f292eb8581f1df7459600cc33... <https://github.com/df-com/dragonfly/blob/9dfcbc1153f292eb8581f1df7459600cc33... > https://github.com/nofe1248/Helium/blob/92ec4452b8c05e6d86c972f843196a4392a7... <https://github.com/nofe1248/Helium/blob/92ec4452b8c05e6d86c972f843196a4392a7... > https://github.com/LagrangeDev/liblagrange/blob/10e3b48f8d47fd65de00b14cfed6... <https://github.com/LagrangeDev/liblagrange/blob/10e3b48f8d47fd65de00b14cfed6... > https://github.com/yudaichen/feature-db/blob/e94ade969af682ed5dd25d70bf282ba... <https://github.com/yudaichen/feature-db/blob/e94ade969af682ed5dd25d70bf282ba... > This is not a complete list even for my search only and I believe there are other patterns to use boost with modules now (e.g., at least `*.cppm` is not the defacto suffix). And I also believe, from my experience as a C++ user, if boost provide modules, I may try to use it. But if boost didn’t provide it, maybe I won’t ask for it if I don’t want modules super bad. Since modules doesn’t add any new functionality actually. So most users may not ask for it explicitly. But if boost provides it, people may give it a try. The above text are the body of the post. I hope it can show it is needed. — Following of are some technical discussion for the extra maintainance burden by introducing modules. The conclusion is, I think, the burden is pretty low. Since modules are not complex to users. Different from other big features in C++, modules are pretty easy to understand. The complexity of modules are majorly on tools and the ecosystem. For programmers who don’t get involved to much to the ecosystem (or infrastructure), modules should be pretty easy to understand. 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. - In headers, include standard headers and other dependent headers conditionally so that we don’t include anything if the headers are in a module unit. e.g., https://github.com/boostorg/pfr/blob/f09e6aeae9d050897fff72b93d5f5e866cc5e11... <https://github.com/boostorg/pfr/blob/f09e6aeae9d050897fff72b93d5f5e866cc5e11... > then that’s roughly all you need for maintaining it at source level. For building and distributing related things, anarthal told me that the boost will handle it globally so the individual arthors don’t need to care about it. — In slack, there are some other discussion about module names and linking problems (https://cpplang.slack.com/archives/C27KZLB0X/p1734345716728609 <https://cpplang.slack.com/archives/C27KZLB0X/p1734345716728609 >). But I feel they are implementation details. I may not talk too much for that as a user at least now. And also there are opinions for configuration flags. These are the jobs of build systems (cmake is working on it). I think boost don’t need to worry for that. Similarly, at least libc++ has similar problems but libc++ still released std module. — 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”. Thanks, Chuanqi