On Fri, Nov 03, 2023 at 12:39:35 -0400, Tom Honermann via SG15 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;

This reminds me…Bjarne's "profiles" proposals are likely to introduce
macros here as well:

    #define MY_PROJECT_SAFETY_PROFILES [[profile(safety_a)]]
    // …
    export module X MY_PROJECT_SAFETY_PROFILES;

The grammar rules may ban this for scanning. Of course, if we're going
to say that attributes cannot affect BMI matters, then we can ignore
them. If they affect BMI usage (e.g., if `import X;` needs a different
BMI than `import X [[profile(thread_safety)]];`), then we will still
likely need macros. Or a good story for users as to why *these*
attributes must be typed by hand/generated code and not
preprocessor-selected.

I do need to ask Bjarne about the semantic meaning of these profile
attributes to the BMI.

--Ben