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@lists.isocpp.org> wrote:
Michael Spencer via SG15 <sg15@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15