I'm a bit torn here.

On one hand, I'm not a fan of module names in *export or import*
declarations being subject to macro expansion for discoverability reasons.
On the other hand, I can see valid use cases to manipulate said module
names.

I think, the problematic part is that macros in module names can become
know only after preprocessing the global module fragment. If I
understand the concerns correctly, macros coming from the commandline
are easy to handle because those are known *before* the compiler invocation.

Wouldn't this be a viable path to simplify discovery *and* offer the
option of specifing module names in an injectable way. I'm not a
preprocessor specialist, but can we talk in the standard about macros
that need to exist before the start of processing a TU?

Thanks
   Dani

Am 03.11.2023 um 09:57 schrieb Bret Brown via SG15:
> I'd like to hear use cases that require or benefit from preprocessing
> compared to other approaches like some mild code generation.
>
> So far, I'm inclined to restrict preprocessing as proposed. Among
> other reasons, preprocessing tricks are more error prone from an ODR
> perspective, so they're already problematic. An interface with those
> sorts of tricks would have to be carefully paired with preprocessing
> instructions, for instance. We are working on mechanisms to support
> that, but they do not exist yet, not portable ones anyway.
>
> More, I think the point in the paper about this not being a breaking
> change is very valid. There really aren't any existing use cases to
> break. Hypothetical use cases are interesting, but mostly if they
> derive from clear needs for modules to be useful. I would include
> practical matters of adoptability as "clear needs", for what it's worth.
>
> That being said, the paper seems to be hinting at significant
> performance savings in certain combinations of codebase arrangements
> and (I assume) clang and/or clang-scan-deps calls. It would be
> interesting to see some performance indicators for these situations
> shared in addition to the more abstract reasoning provided in the paper.
>
> Bret
>
> On Fri, Nov 3, 2023, 03:43 Boris Kolpackov via SG15
> <sg15_at_[hidden]> wrote:
>
> Michael Spencer via SG15 <sg15_at_[hidden]> writes:
>
> > This paper makes the following ill-formed by forbidding macro
> expansion
> > in the name of module declarations.
> >
> > version.h:
> > #ifndef VERSION_H
> > #define VERSION_H
> >
> > #define VERSION libv5
> >
> > #endif
> >
> > lib.cppm:
> > module;
> > #include "version.h"
> > export module VERSION;
>
> What about something like this:
>
> #ifdef VERSION
> export module version;
> #else
> export module final;
> #endif
>
> Sounds like it will pose the same issue but banning it feels more
> drastic.
>
> Even the use of a macro in the module name could probably have
> plausible use-cases. Say if you are trying to make a module
> that includes a version in its name:
>
> #define VERSION 2
> #define VERSIONED_NAME(n) n ## _v2
>
> And then:
>
> export module VERSIONED_NAME(utility);
>
> #if VERSION >= 2
> export void only_available_in_v2 ();
> #endif
> _______________________________________________
> 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