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

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2025-01-12 21:15:06

On Sun, 12 Jan 2025, 22:10 Peter Dimov via Boost, <boost_at_[hidden]>
wrote:

> Ruben Perez wrote:
> > Hi all,
> >
> > I finally have something workable regarding Boost and C++20 modules.
> > I've described it in detail in this article [1], but here's a rough
> > summary:
> >
> > I've modularized Boost.Mp11 [2] (as an example of a header-only
> > library) and Boost.Charconv [3] (as an example of a compiled library).
> ...
> > Other than that, I'd like to get some feedback on this, and whether you
> think
> > this proposal is worth the effort.
>
> I looked at the Mp11 patch, and I think I don't quite like this approach.
>
> At present, user code needs to look like this
>
> #ifdef BOOST_USE_MODULES
> import boost.mp11;
> import boost.core;
> import std;
> #else
> #include <boost/mp11/this.hpp>
> #include <boost/core/that.hpp>
> #include <standard_header>
> #endif
>
> and I'm not sure that this is what we want.
>
> Rather, my current thinking is that we want this for user code:
>
> #include <boost/mp11/this.hpp>
> #include <boost/core/that.hpp>
> #include <standard_header>
>
> with boost/mp11/this.hpp being
>
> #ifdef BOOST_USE_MODULES
> import boost.mp11;
> #else
> #include <boost/mp11/detail/this.hpp>
> #endif
>
> This would presume that <standard_header> does something similar,
> which is in fact one suggested implementation strategy.
>
> If not, we'll need
>
> #include <boost/mp11/this.hpp>
> #include <boost/core/that.hpp>
> #include <boost/std/standard_header.hpp>
>
> which is not ideal, but is still better than what we started with.
>
> In the general case (when a header also defines macros), the public
> header will contain both
>
> import boost.mp11;
>
> and the part that defines the macros, which in Mp11's case is
>
> #include <boost/mp11/version.hpp>
>
> User code wouldn't need to know that in addition to the import,
> it also needs to include a separate macro header.
>

This is an interesting idea. Standard library headers don't do this
(although making them do it would be... relieving).

I will have a try to your approach next week.

Thanks,
Ruben.