That is likely the best way to achieve what you and others in your field of
interest need. Honestly, looking at reflections, attributes, template for,
and the whole list of new features, I just can't help but imagine the
amount of new beautiful tools that will come out. This mailing thread is a
great example of that. I had this project that took me a thousand lines of
code (for dynamic runtime memory) to write( even with macros ), but now
it's gonna be less than 200 lines of clean code. I am happy that you found
what you needed as well and dearly hope you work on it, make it public,
perhaps write about the implementations that you worked on and send me a
link. To the future!

On Wed, Oct 28, 2026 at 3:43 AM A Johnston <ajohnston54637_at_[hidden]> wrote:

> I appreciate the way you unpacked that. We seem to share the same
> technical grievances.
>
> It is easy to say that "being able to go through some barriers has a lot
> of value, and for others there is not a lot." And arguably, combining
> reflection, enhanced compile time processing, and arbitrary annotation of
> the compilers parse tree, represents a valuable destination to arrive at.
> That is why those features just went into the standard.
>
> Having arbitrary annotation of the compilers parse tree available offline
> is also very interesting in the bindings generations world. So much so that
> I am back on here talking about that online/offline barrier and the
> cost/benefit of it.
>
> Perhaps an attribute named "api" is all I need:
>
> [[api("command")]] void example_command(void);
>
> It wouldn't have any specified meaning in the standard except to signal to
> static/dynamic bindings generation code that the labelled function was to
> be exported under undefined circumstances.
>
> That would probably be enough for a tooling ecosystem to appear around
> that tag.
>
> Here are some other examples: [[api("Python")]], [[api("C")]], [[api]].
>
> Then people who are not the compiler venders can pick up the ball. I'd
> recommend using the debug data to implement static bindings generation
> myself. If it is being done at compile time then there is no harm in having
> debug symbols. So why reinvent them.
>
> On Mon, Oct 26, 2026 at 9:43 PM Muneem via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> 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
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>