I think this and other similar ideas have some merit - there are
certainly many things that could be done at build time with a more
sophisticated build model. But I do not think they can be added on to C++.

C++ has a build model where each translation unit (generally, a .cpp
file) is separately compiled to an object file, and then these are all
linked together based solely on (mangled) identifier name. This is a
very old idea, and is the method used for most (but not all) fully
compiled languages. While some toolchains do more than this (link-time
optimisation, and similar technologies), changing this model would be a
massive disruption to the language. Metaclasses would be easy in
comparison.

Of course a language and build model where translation units could
interact at compile-time would allow for many fun new toys -
"compile-time variables" would be just a little one. Private members of
classes and inline function implementations could be in cpp files rather
than headers. Enums could be defined in bits, in different units.
Arrays and other containers could build-time initialised with parts in
different files. Gui concepts like slots, signals, and events could be
significantly more efficient. Static analysis of resource ownership and
usage, and data and thread race checking would make Rust look as
advanced as Fortran 66.

But trying to define such a build model for a new language would be very
difficult - making it efficient, scalable and usable for a wide range of
hosts, targets, implementations, and use-cases would be a major
undertaking. Trying to retrofit it to C++ with its existing code bases
would, I think, be infeasible. And I don't think it would be possible
to implement just a small bit of it - like "compile-time variables" -
without a total restructure of the build model.

The best you can do, I believe, is using pre-processors that extract
bits of code or information from the source code and generate new
headers or implementation files from that information. You do your
"compile-time register" feature by writing "REGISTER(foo)" in your code,
where "REGISTER" is a macro that does nothing. Then you have a script
that runs through each of your source code files looking for that
pattern, and generates a new source code file using the given functions
as a constinit initialiser for a vector (or whatever). It is all
specific to the project, and requires manual integration in your
makefiles or other build system. But people can, and do, make this kind
of thing work.

David





On 14/07/2025 10:14, SD SH via Std-Discussion wrote:
> There is a new idea: execute code after compiling, before running,
> called pre-execution.
> Then we have 3 stages to run code:
> compile-time -> pre-execution -> runtime
> Pre-execution can use the result of compile-time code, while
> compile-time code cannot use the former,
> and runtime code is similar.
> Follow this idea, it won't break the existing compile-time features, and
> we can slove the problem before, and it costs less time than the last.
>
> Actually some projects and languages did it, such as Unreal Header Tool
> and build.rs of Rust.
>
> Do you think it's feasible or not?