Maybe it'll be better to import std in the modules

[ChuanqiXu9]

Hi, excited to see the experiments in https://anarthal.github.io/cppblog/modules2

I just want to note that it may better to improve the experiments by importing std module in the library itself.

For example, for https://github.com/cppalliance/boost2/blob/master/libs/math/module/core.cxx we can rewrite it as:

module;

#define BOOST_MATH_POLICIES_AS_MODULE
#define BOOST_MATH_AS_MODULE
#define BOOST_MATH_STANDALONE


#if STD_MODULE_AVAILABLE
import std.compat;
#else
// For config:
#include <algorithm>  // for min and max
#include <limits>
#include <cmath>
#include <climits>
#include <cfloat>
#if (defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__))
#  include <math.h>
#endif
#include <type_traits>
#include <cfenv>

// For error_handling.hpp and policies.hpp:
#include <iomanip>
#include <string>
#include <cstring>
#include <typeinfo>
#include <cerrno>
#include <complex>
#include <cmath>
#include <cstdint>
#include <stdexcept>
#include <boost/math/tools/mp.hpp>
#include <boost/math/tools/config.hpp>
#include <boost/math/tools/throw_exception.hpp>
#include <sstream>
#include <limits>
#include <cstdint>
#include <cstddef>
#include <boost/math/tools/assert.hpp>
#include <limits>
#include <climits>
#include <cstdint>
#include <cfloat> // LDBL_MANT_DIG

...
#end STD_MODULE_AVAILABLE

Also in https://github.com/cppalliance/boost2/blob/master/libs/math/module/sf.cxx, I see you tried to import std, but at least that won't work for libc++

module;

#define BOOST_MATH_SF_AS_MODULE
#define BOOST_MATH_AS_MODULE
#define BOOST_MATH_STANDALONE

#if defined(__cpp_lib_modules) && __cpp_lib_modules >= 202207L

import std;
import std.compat;

#else

#include <cmath>
#include <climits>
#include <algorithm>
#include <type_traits>
#include <cstdint>
#include <limits>
#include <mutex>
#include <vector>
#include <string>

#endif

#include <boost/math/tools/promotion.hpp>

export module boost.math.special_functions;

Since __cpp_lib_modules is defined by the library, but we didn't include any library here. Also __cpp_lib_modules is not defined by libc++. So we probably have to do something manually here.

[mborland]

I agree we should try importing std as well. The MSVC Preview 17.10 and CMake 3.30 should support this more easily in the near future.

Shouldn't libc++ be defining __cpp_lib_modules in <version>? I guess that could be the first include so that it's easy to check for import std support.

[ChuanqiXu9]

Shouldn't libc++ be defining __cpp_lib_modules in ? I guess that could be the first include so that it's easy to check for import std support.

I guess the reason is that the std module is still under experimental in libc++. I've registered llvm/llvm-project#89579 to track that.

[anarthal]

Hi! My second experiment does that (MSVC's STL is more strict than libc++ regarding include/import mixtures): https://github.com/anarthal/modules-playground

Actually, measurements in the cited article use the repo I link, rather than the original one. I didn't note my results anywhere, but I re-measures clean build times with import std in the Asio module and they were equivalent. It looks like the time saved by import std is spent building the std module. This is good news though: if we have 50 Boost modules, the time spent building std will be consumed just once, instead of 50 times.

The original repo used #include <std> because it allowed us for a non-intrusive approach, which was attractive because not all Boost maintainers are very engaged with modules. import std is much better but won't work without appropriately #ifdef-ing out standard includes in all our libraries. If an author refuses to merge such changes, the entire chain breaks.

[ChuanqiXu9]

Fair enough. Thanks. Also it should be helpful to avoid redeclarations in different TUs in the reader side: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#reduce-duplications

I'll close the issue since they are different projects.

[anarthal]

I think the takeaway is that the way to go would be to make all libraries modules and import them rather than including them, as described in https://anarthal.github.io/cppblog/modules2.

[ChuanqiXu9]

Yes! And to make that happens, the role of fundamental libraries are pretty important. Otherwise the users in the upper level can't only wrap the third party libraries by them selves...

[mordante]

Shouldn't libc++ be defining __cpp_lib_modules in ? I guess that could be the first include so that it's easy to check for import std support.

I guess the reason is that the std module is still under experimental in libc++. I've registered llvm/llvm-project#89579 to track that.

@mborland @ChuanqiXu9 Thanks for pointing out this omission, this was an oversight. I've created a PR to fix this in libc++. (I'm the author of modules in libc++.)