On 11/3/23 2:51 PM, Bret Brown via SG15 wrote:
> Regarding scenario 1 of Tom's email, couldn't a separate X module just
> re-export the contents of the Twitter module? Why does the redirection
> have to happen in the same source file?
That seems plausible, yes, and the re-export could go in either
direction and be provided on either the producer or consumer side.
>
> Regarding scenario 2, you either have an ODR risk with multiple
> libraries providing the same symbols, or you have different symbols
> (perhaps because of symbol mangling incorporating module names) and
> the scenario is perhaps moot.
I was imagining that, for a given build, the module would only ever be
resolved against a single module provider.
>
> And, as I said in a previous email, these aren't existing use cases,
> just hypothetical ones. Though I do agree we need to have useful
> mechanisms for migrating users from one module to another, I am not
> sure any specific scenarios require preprocessor features. Again, keep
> in mind that very mild code generation is as flexible as preprocessing
> in all cases, especially considering the need to carry around
> consistent preprocessor definitions next to shipped header files for
> ODR coherency.
I don't agree with code generation being as flexible as preprocessing;
it can have a significant impact on tooling. For example, if the code
generation is transient (the source file is written to a temporary
space, compiled, and then removed), then the source code doesn't remain
available for use by other tools.
>
> And we can always revisit our cost/benefit analyses in the future as
> concrete situations arise. It's relatively cheaper to add
> preprocessing features later than to try to back them out after
> modules get real adoption.

Agreed.

Tom.

>
> Bret
>
> On Fri, Nov 3, 2023, 12:39 Tom Honermann via SG15
> <sg15_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.
>
> 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
> _______________________________________________
> 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