Re: So.... what are we going to do about modules?

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2022-04-05 19:27:23

On 05/04/2022 18:49, Daniela Engert via Boost wrote:
> Am 05.04.2022 um 19:47 schrieb Niall Douglas via Boost:
>> On 05/04/2022 18:34, Peter Dimov via Boost wrote:
>>> My ambitions are modest. All I want is to be able to do this:
>>>
>>> #if BOOST_MODULES_SUPPORTED
>>>
>>> import <cstddef>;
>>> import <type_traits>;
>>> import <exception>;
>>> import <initializer_list>;
>>> import <utility>;
>>> import <functional>; // std::hash
>>> import <cstdint>;
>>> import <iosfwd>;
>>>
>>> #else
>>>
>>> #include <cstddef>
>>> #include <type_traits>
>>> #include <exception>
>>> #include <initializer_list>
>>> #include <utility>
>>> #include <functional> // std::hash
>>> #include <cstdint>
>>> #include <iosfwd>
>>>
>>> #endif
>> The compiler will automatically as-if do the above for you if Modules
>> are enabled for standard library headers. It's clever enough to
>> interpret an include as an import. So no need.
>>
> Right, but this part of the standard is optional. MSVC has it but not 
> the others, right?

clang has it too.

GCC will have it soon, from what I've heard, once their Modules 
implementation is more mature.

That's all three major compilers. Me personally, I'd consider this not a 
thing to worry about.

Re: auto conversion of non-std includes to module imports, Outcome does 
it by simply having the include do the import if it detects modules 
enabled. Then no end user source code needs to change. #include is 
always the right thing to document and to do.

If Boost ever modularises, I'd suggest the exact same technique, and 
then nobody needs to upgrade their Boost including code.

Niall