On Fri, Jul 11, 2025 at 1:45 PM SD SH via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> >Variables in functions executed at compile-time need not be constants.
> So, are you asking for a variable which exists across translation
> units that isn't a compile-time constant?
> Right.
> >Where compile-time code in
> different translation units can read from and modify such variables?
> Need more discussion, maybe by defining and using storage class?
> >How would that actually work? Like, somebody's got to read it first,
> right? Somebody's got to write to it first. Who decides which TU gets
> first dibs on the variable? Who decides which TU gets to access it
> second?
> By implementation. To be honest, it is only able to use in unordered case, for example, I need to register a lot of update functions to a class to execute them (then deside how it executes), we don't pay attention to the order.

Then it's not a "variable"; it's an accumulator. It's a mechanism that
accumulates values for some purpose.

But even that's not implementable, since there's no way to know when
you have stopped accumulating and can therefore use the value. See
below.

> >Just look at your example: "count the number of instances of a
> template in compile-time". So you have some variable that represents
> that instance count. Is that variable somehow a constant expression?
> >Because if it is, then you should be able to do `array<T,
> instance_count>`. Which is flat-out impossible for a compiler to do
> because any TU could increase that count, and a TU's compiler cannot
> >reach out and look at every TU that could possibly be used with this
> program.
> So it needs more constraints, like be only able to use the value after all change or other.

"All change or other" is an unbounded set. It is not possible for a
compiler to compile a TU after all other TUs have been compiled. Even
if a compiler was given a sequence of TUs to compile, the ability to
link libraries (composed of TUs) exists. So the compiler cannot know
if there are other TUs that will be linked to the program after the
given set of TUs have been compiled.

> (Inneed, it brings many difficulties, that's known, and it is the reason of this discussion. We should try more new design.)

Then you're going to need to justify this with *compelling* use cases
first. Upending the basics of how linking works in the language is not
something that should be done because someone wants to "count the
number of instances of a template" (which is a thing I've never wanted
and find the idea that it is useful to know to be quite dubious).

If you're going to open up Pandora's Box, there'd better be something
extremely useful inside it that a lot of C++ programmers have a real
need for.