You are basically looking at a feature that is always local to a
translation unit, and you expect the compiler to generate code so that when
the linker links the code then it will run with those features across both
files being linked. You can clearly see the problem here, don't you think?
Like I said, you need to expand modules so that they bypass the linker
entirely and the issue with that is also that you will have larger compile
times when ever you want to compile one file since every file is basically
using another. Find a way to magically bypass this overhead, you will have
yourself a great proposal, and something everyone will be down for. One
obvious way to bypass it is to not include code directly but rather include
compiled code, and then inspect that, but then the issue is that you have
to make it mantondory for the compiler to make sure that every object file
created has meta info embedded in it in someway. At the end,
metaprogramming is magic, but it isn't really all magic like you can't use
a magic wand to do magic, you have to have something to stand on. Your only
closest bet here is with BMI files but even that isn't the best built
performance wise the most perfect thing. it will also force you to make a
hierarchy of files, the ones above will import the BMI files of the ones
below, which again will require build scripts. At the end, all you can see
is that what you are proposing as a way to configure your project at build
time will have to be done using scripts, even with BMI support.

On Tue, 27 Oct 2026, 4:35 am A Johnston via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> >> Which proposals are you referring to?
>
> It was, "P3394R4, Annotations for Reflection" and P3795R2 that were
> adopted in C++26. So this is what C++ programming looks like now:
>
> ```
> struct Args {
> [[=clap::Help("Name of the person to greet")]]
> [[=clap::Short, =clap::Long]]
> std::string name;
>
> [[=clap::Help("Number of times to greet")]]
> [[=clap::Short, =clap::Long]]
> int count = 1;
> };
> ```
>
> Personally, I'm down for it. After writing macros for all this in C++98,
> and seeing enough people crater writing introspection without language
> support, I think language support is great.
>
> This is going to disrupt the current ecosystem around C++ script bindings
> because they have had to rely on complex template metaprogramming that
> takes a relatively long time to compile and can generate bad code.
>
> The point I was initially trying to make, is that these attributes allow
> you to describe a command language. And that implementing a "command
> language" is very generic, and I would like something that consumes a
> command language to be able to discover it in a generic way too.
>
> E.g. how do I enumerate the functions in a previously compiled module,
> scanning for those designated as being that modules commands and generate
> the flavor of bindings expected for those? I figure, at this point, it is
> just a question of whether the standard commits to a few attribute names
> for commands and how to discover them or Google picks a standard and we
> copy that.
>
>
>
>
>
> On Sun, Oct 25, 2026 at 9:53 AM Bjorn Reese via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On 10/24/26 22:06, A Johnston via Std-Proposals wrote:
>>
>> > I only have one major complaint that is unresolved in the online
>> > discussions around attributes proposals that I have read:
>>
>> Which proposals are you referring to?
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>