There is another fundamental misunderstanding here.

The feature calls to "record all the orthogonal template parameters".

While that's not what that word means, I think regardless it's asking for
global enumeration. C++ has a separate linking model. All the
types/functions are not known within a single unit. The xunion is
impossible to compute.

This is a sister problem to what Jason is highlighting.

On Fri, Aug 2, 2024, 00:24 Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, Aug 1, 2024 at 6:56 PM organicoman via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Tiago,
> > I got your analogy perfectly, you are reiterating what you said about
> how much to allocate...etc.
> >
> > Allow me to explain:
> > 1- main motivation:
> > template<int T>
> > int F(int x) { return T * x + 1; }
> > int main()
> > {
> > vector<int(*)(int)> vec;
> > vec.push_back(&F<1>);
> > vec.push_back(&F<2>);
> > vec.push_back(&F<3>);
> >
> > for(const auto& f : vec)
> > {
> > cout << "function parameterized on t = " << /*some call to get
> the non-type template value*/ << endl;
> >
> > cout << "ret val =" << f(10) << endl;
> > }
> > }
> >
> > Despite the information about the template value is known, yet i connot
> access it from out side the function, why???
>
> "Known" by who? See, the fundamental problem is that the information
> is not known. That's because it's not part of the function.
>
> Consider this:
>
> ```
> int i = k + j;
> ```
>
> Can I use `i` to access `k` or `j`? No.
>
> why???
>
> Because the value of `i` has already been computed by this expression.
> `k` and `j` were accessed, the results of access had `+` applied, and
> the result of that was coerced into an `int` for storage into `i`.
>
> From that point forward, `k` and `j` are *completely uninvolved* with
> `i`. You cannot reach back and access `k` or `j` through `i`.
>
> A function pointer is a *value*. And that value works like *every
> other kind of value* in C++. It gets computed and it gets stored, but
> you cannot use the stored value to reach back and interrogate *how*
> that value got there.
>
> The expression `&F<1>` computes the value of a function pointer. That
> value does not in any way contain any information about `F` or `1`.
> The value itself does not know how it got there; all it knows is that
> it has a certain value. As such, you cannot reach through that value
> to figure out how it got there, to query properties about how that
> value came to be.
>
> The thing you're trying to do is introspect the compile time
> properties of the expression that led to the production of a runtime
> value.
>
> > Maybe i want to create an abacus of that function against the value of
> T!!
> > That's the whole purpose of my proposal.
>
> That's not motivation though; it's an artificial example of how the
> feature can be used. The question is what problem it solves. Show a
> problem, preferably one that real C++ programmers face, which this
> proposal will solve.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>