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.

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