Regarding scenario 1 of Tom's email, couldn't a separate X module just re-export the contents of the Twitter module? Why does the redirection have to happen in the same source file?

Regarding scenario 2, you either have an ODR risk with multiple libraries providing the same symbols, or you have different symbols (perhaps because of symbol mangling incorporating module names) and the scenario is perhaps moot.

And, as I said in a previous email, these aren't existing use cases, just hypothetical ones. Though I do agree we need to have useful mechanisms for migrating users from one module to another, I am not sure any specific scenarios require preprocessor features. Again, keep in mind that very mild code generation is as flexible as preprocessing in all cases, especially considering the need to carry around consistent preprocessor definitions next to shipped header files for ODR coherency.

And we can always revisit our cost/benefit analyses in the future as concrete situations arise. It's relatively cheaper to add preprocessing features later than to try to back them out after modules get real adoption.

Agreed.

Tom.

Bret

On Fri, Nov 3, 2023, 12:39 Tom Honermann via SG15 <sg15@lists.isocpp.org> wrote:

Please correct me if I'm mistaken, but at this point, module names are used only to map a module-import-declaration to a corresponding module-declaration (in another translation unit) and we have no actual proposals to use module names for any other purposes. If so, then my only hesitation with prohibiting use of macros for module names is whether there might be more motivation for configurable module names in the future.

I can only think of two reasons to support configurable module names at present:

1. To allow module names to be changed without breaking backward compatibility:
   import Twitter.api; -> import X.api;
2. To allow a generic module name to be resolved to one of multiple module providers:
   import ldap.provider;
   

Perhaps these use cases could be satisfied by introducing a module alias declaration (in a future proposal).

module ldap.provider = mozilla.ldap;

Handling this declaration would then require preprocessing as it would presumably reside within an #ifdef chain; a dependency scanning tool would need to be able to fall back to a preprocessing mode if such a declaration were present (which would presumably be rare). I don't have a good sense of how feasible that is.

The ability to change module names without breaking backward compatibility is something I think the paper should discuss. If the preprocessor can't be used for this purpose, then code generation will be the only other option available and that doesn't scale. The desire to be able to change module names over time will increase if we introduce additional ways to refer to them.

The highlighting for the proposed wording changes is not accurate for the grammar terms. The changes appear to be all additions, but those terms are already present in the standard with slightly different names.

Tom.

On 11/3/23 1:02 AM, Michael Spencer via SG15 wrote:

I have a paper discussing an issue for build systems we've recently hit with discovering which source file defines the interface of a given named module.

Thanks,

- Michael Spencer

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15