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.

Bret

On Fri, Nov 3, 2023, 12:39 Tom Honermann via SG15 <sg15_at_[hidden]>
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 listSG15_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>