[Daniel]
> Any transition to modules will very likely require
> mixing usage via headers and usage via named modules in the same
> program.

See for example, how @Stephan T. Lavavej implemented to-be-C++23 standard library module `std`: see https://github.com/StephanTLavavej/STL/tree/import-std

> My understanding, and I'd like some confirmation, is that you can
> export a redeclaration from the global module fragment into the named
> module.

Yes: Just put your declaration in 'extern "C++"' if it is in the purview of a named module.

If your compilers always understand modules, you can also implement things the other way around: have the header file say "import My.Module;". And if you do that, even your header files get some isolation.

Or, if you don't want to do the work needed for proper isolation just say "export import <my-header.h>;" in your named module -- of course, you don't get much from modules if you do that, other than having a grep match of new keywords.

Or, don't create more technical debts for yourself if you don't have the resources.

-- Gaby

-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniel Ruoso via SG15
Sent: Wednesday, May 25, 2022 6:31 AM
To: René Ferdinand Rivera Morell via Ext <ext_at_[hidden]>
Cc: Daniel Ruoso <daniel_at_[hidden]>; WG21 Tooling Study Group SG15 <sg15_at_[hidden]>; Nicolai Josuttis <nico_at_[hidden]>
Subject: Re: [SG15] [isocpp-ext] How to provide functionality as both header file and module?

Em qua., 25 de mai. de 2022 às 01:19, Nicolai Josuttis via Ext
<ext_at_[hidden]> escreveu:
> However, their code is not necessarily only used within projects that use a build system.
> It is a little piece of functionality useful in all kinds of programs (a key attribute of header files today).

This comes up even regardless of the requirement to have a build
system or not. Any transition to modules will very likely require
mixing usage via headers and usage via named modules in the same
program.

> They want to avoid double-written code or scripts to transform code form one format to another (header files to module or vice versa)
> And they really do not want to deliver/provide two different files of C++ code for the same functionality.
> Which results in the following question:
> What is the best approach / trick / hack to provide single-source code that can be used as both header file and module?
> Or should customers in situations like this not replace header files by something that supports modules at all?

My understanding, and I'd like some confirmation, is that you can
export a redeclaration from the global module fragment into the named
module. So you'd end up with something like

mylibrary/component.h
```
namespace mylibrary {
  class Component { ...
  };
}
```

mylibrary/component.ixx
```
module;
#include "mylibrary_component.h"
export module mylibrary.component;
namespace mylibrary {
  export class Component;
}
```

That way a codebase that wants to start using `import
mylibrary.component` while some of the source files still say
`#include <mylibrary/component.h>` would have a reasonable transition.

daniel
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&amp;data=05%7C01%7Cgdr%40microsoft.com%7C75e0fa3397ea42f3234608da3e52d679%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637890822752796649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=11ekL%2Bs48L7q4m2nThB9WJjha%2BV%2BUTR70wQNU2KDKRA%3D&amp;reserved=0