On Fri, Nov 3, 2023 at 9:39 AM Tom Honermann <tom_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.
>

`import` requiring preprocessing is fine, as you already need to be
preprocessing the file anyway to figure out its actual dependencies. So
`import LDAP_PROVIDER;` or an `#if` block is fine here already. I think the
best way to do it though would just be:

```
export module ldap.provider;
#if CONFIG1
export import ldap.option1;
#else
export import ldap.option2;
#endif
```

Which also has less ABI breakage if configs ever end up getting mixed in
the same program.

It's hard to reason about potential use cases we don't know about yet, but
so far I just don't think there's any case where using a macro for a module
name is actually needed, and in every case so far it seems actively worse
than the alternative.


> 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.
>

It was my understanding that we need different grammar rules for the
preprocessor vs. normal parsing, but if we can use the same ones that's
fine.

- Michael Spencer


> 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
>
>