On 11/4/23 1:51 AM, Michael Spencer via SG15 wrote:
> 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.
Thanks, that does seem reasonable.
>
> 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.

Ah, my bad. I was comparing against [module.unit]
<http://eel.is/c++draft/module.unit>, not against [cpp.module]
<http://eel.is/c++draft/cpp.module>.

Tom.

>
> - 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 list
>> SG15_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15