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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-12-22 12:38:57

Ruben Perez wrote:
> On Sun, 22 Dec 2024 at 13:10, Peter Dimov via Boost <boost_at_[hidden]>
> wrote:
> >
> > Ruben Perez wrote:
> > > 3. Some libraries support configuration macros. For instance,
> > > Boost::throw_exception supports BOOST_NO_EXCEPTIONS. This is used
> by
> > > other Boost libraries to support builds that disable exceptions. In
> > > the current world, the end user defines BOOST_NO_EXCEPTIONS in their
> > > code, includes the library, and everything works. Using a scheme
> > > like the one I suggested requires the user to build all the Boost
> > > modules using BOOST_NO_EXCEPTIONS, which is more involved than
> what we have today.
> >
> > BOOST_NO_EXCEPTIONS is not defined by the user. It's defined by
> > Boost.Config when -fno-exceptions or an equivalent is used.
> 
> Thanks for the clarification.
> 
> I think the same considerations still apply: if the user wants -fno-exceptions,
> they would need to build the Boost modules with that flag if we follow what
> the CMake guys recommended.

I was going to say that the same applies to the -std level, but it occurs to me
that in order to build and use modules, you need at least -std=c++20 anyway
so most such issues won't manifest for now, until we get conditional uses
of C++23 or C++26.

We also have an interesting problem with -fno-exceptions; the function
boost::throw_exception in that case is only declared on our side, but defined
by the user. This (I think) means that the declaration can't be exported by the
module, it needs to appear in the GMF. Maybe.

At the beginning I'd probably not bother with modularizing Assert (which mostly
exports macros anyway) or ThrowException.

By the way, I posted about the optional `export` idea to the committee mailing
list, and Michael Spencer replied and basically said "don't".

"My suggestion is to do either `export import <boost/foo.hpp>;` in the module
if you are ok with getting extra declarations, or `export using ...` like libc++ does.
Trying to textually include a header into the purview of a named module is
fraught with issues."

Since everything that's textually included becomes attached to the named
module, it's too easy to create ODR violations.

But, apparently, Clang doesn't like header units, so the above is also not quite
optimal.