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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15