On Sun, Aug 23, 2020, 10:13 Mike via Boost wrote:

<...> I think the real problem is that - due to the structural differences it may not be possible to conditionally turn a header file into a module interface unit just with a bunch of #ifdefs in a convenient manner, and even if you could, code using boost modules could not coexist with code using boost headers.

I think that it is solvable. In each header put something like that in the beginning: #if defined(__cpp_modules) && !defined(BOOST_VARIANT_BUILD_MODULE) import boost.variant #else // include guards #ifndef BOOST_VARIANT_HPP #define BOOST_VARIANT_HPP #endif #endif Now `import boost.variant;` and `#include ` could coexist. Also all the users just gain the benefits of modules if compiler supports them.

Gesendet: Sonntag, 23. August 2020 um 19:09 Uhr Von: "Zach Laine via Boost" An: "Boost mailing list" Cc: "Zach Laine" Betreff: Re: [boost] Modules

On Sun, Aug 23, 2020 at 2:13 AM Mike via Boost wrote:

...

...

Gesendet: Sonntag, 23. August 2020 um 00:40 Uhr Von: "Zach Laine via Boost" An: "Boost mailing list" Cc: "Zach Laine" Betreff: Re: [boost] Modules

On Fri, Aug 21, 2020 at 1:54 PM Damian Vicino via Boost wrote:

...

Hi, Are there any guidelines on the use of modules inside boost? Are we planning any steps for adoption of them?

Modules are pretty hard for most Boost libs to adopt. Consider how many times we have code like this:

#if BOOST_LIBNAME_DO_WHATEVER some_code; #else come_other_code; #endif

That cannot exist inside a module. The net result is that your code has to be all the same lexically -- for all compilers and platforms -- if it is in a module.

Are you sure? I've never hear of such a restriction.

Yes, although it may not be clear what I mean. You can only have preprocessor directives before the keyword module:

#ifdef SOMETHING // ok #include "foo.h" // ok #endif // ok

module foo;

#ifdef SOMETHING // error #include "bar.h" // error #endif // error

Could you maybe point me to the relevant location in the standard? A quick test with compiler explorer (https://godbolt.org/z/EP18s1) turns not up any errors, but of course I doubt any compiler implements modules completely to spec yet.

[...]

...

However, you should be able to do the same as other legacy libraries: Make sure your headers can be used as header units and/or provide a wrapper module for each library.

Right, it's just that if you have lots of code in common, but just want it to vary a bit, you have to put that code in the module prefix and then export it from the module. It's not the end of the world, but it is anti-idiomatic to all teaching you're likely to see about how to write modules.

Not sure to which of the two suggestions you are replying, but I really don't understand why it should require any work for most of boost (except maybe the PP library) to be consumable as a header unit. And for a wrapper module, what I have in mind is something like: module; #include export module Boost.Variant; namespace boost { export using boost::variant; } But I'm absolutely no modules expert. Mike

Zach

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Sun, 23 Aug 2020 at 22:34, Zach Laine via Boost wrote:

On Sun, Aug 23, 2020 at 1:35 PM Mike via Boost wrote:

...

Could you maybe point me to the relevant location in the standard? A quick test with compiler explorer (https://godbolt.org/z/EP18s1) turns not up any errors, but of course I doubt any compiler implements modules completely to spec yet.

No, because it looks like that changed! The rule I had in my head is from a previous version of the feature. Sorry for the noise.

It is, however, worth noting that if you have, say, 16 different possible preprocessor outputs, you can just ship one header with the preprocessor conditionals that with their different values give you 16 programs, but you need to ship 16 modules to get the same result in a modular world.

Gesendet: Sonntag, 23. August 2020 um 21:43 Uhr Von: "Ville Voutilainen via Boost" An: "boost@lists.boost.org List" Cc: "Ville Voutilainen" Betreff: Re: [boost] Modules

On Sun, 23 Aug 2020 at 22:34, Zach Laine via Boost wrote:

...

On Sun, Aug 23, 2020 at 1:35 PM Mike via Boost wrote:

...

Could you maybe point me to the relevant location in the standard? A quick test with compiler explorer (https://godbolt.org/z/EP18s1) turns not up any errors, but of course I doubt any compiler implements modules completely to spec yet.

No, because it looks like that changed! The rule I had in my head is from a previous version of the feature. Sorry for the noise.

It is, however, worth noting that if you have, say, 16 different possible preprocessor outputs, you can just ship one header with the preprocessor conditionals that with their different values give you 16 programs, but you need to ship 16 modules to get the same result in a modular world.

Correct me if I'm wrong, but you can still ship a single module source file with all the conditional. You would need 16 different versions of the cmi (bmi) if you wanted to ship them at all (my understanding is that this is not going to be recommended practice.

On Mon, 24 Aug 2020 at 00:34, Mike via Boost wrote:

...

It is, however, worth noting that if you have, say, 16 different possible preprocessor outputs, you can just ship one header with the preprocessor conditionals that with their different values give you 16 programs, but you need to ship 16 modules to get the same result in a modular world.

Correct me if I'm wrong, but you can still ship a single module source file with all the conditional. You would need 16 different versions of the cmi (bmi) if you wanted to ship them at all (my understanding is that this is not going to be recommended practice.

This is not a correction; you're right. So the sane alternatives are either continuing to ship a header and tell users to just import it, or telling users that they're no longer in a simple "just include/import one file" world and that they now need to build source files in order to get the library parts. Which is different from telling them to link to a library.

Gesendet: Sonntag, 23. August 2020 um 23:16 Uhr Von: "Peter Dimov via Boost"

Mike wrote:

...

And for a wrapper module, what I have in mind is something like:

module; #include export module Boost.Variant;

namespace boost { export using boost::variant; }

Or you could just use `import ` and not need any wrappers.

That's why I previously said

Make sure your headers can be used as header units and/or provide a wrapper module for each library.

A wrapper module has the advantage, that it creates a named module and only exports what is explicitly specified, whereas "just" making sure the headers are importable is much easier to do, but doesn't provide the same level of isolation.

On 24/08/2020 06:34, Mike wrote:

Not sure to which of the two suggestions you are replying, but I really don't understand why it should require any work for most of boost (except maybe the PP library) to be consumable as a header unit.

I haven't really been following modules, so someone please correct me if I'm wrong, but I thought that the point was that they insulated both the inside and the outside from stray symbols. So if the module interface prefix explicitly #includes a "config.h" file then any symbol in that will be visible to both users of the module and the implementation of the module; but if user code #included "foo.h" before importing the module then anything in foo.h would not be visible inside the module. Similarly for #defining anything outside the interface file. Most of Boost.Config and other macros would be fine with this, since they're detecting compiler capabilities that aren't really customisable (although some may depend on compiler parameters, which gets tricky; this includes things like -std=). But this would break a lot of other configuration macros like BOOST_NO_EXCEPTIONS and BOOST_THREAD_VERSION (where they exist explicitly for the app to indicate a preference, or are intended to be influenced by both capabilities and preferences). Perhaps if Boost.Config always explicitly included some well-known header file name (that could somehow be overridden by the app), with a requirement to put all config macros only in there. But then whatever builds the modules would need to happen on a per-consuming-app basis (which may defeat people who want to run b2 only once to build all the libraries and then consume them from multiple apps). I think you can still do the ABI-namespacing tricks to work around some of this (such as having your module export both "v1" and "v2" at all times in different namespaces, but then use macros in a plain header file to control which are actually visible to the consuming code via aliases based on the #defines in effect at the time). But this seems to me to at some level defeat the point of doing modules in the first place. If modules do end up requiring an explicit build step then they also end up turning "header only libraries" into just another kind of static library -- with some advantages and disadvantages over real static libraries, perhaps, but mostly disadvantages over traditional header-only libraries. Hopefully, I'm missing something.