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.Hello Hašper,I will delegate my answer to Thiago.Maciera,I have the feeling that he read my proposal carefully, and pretty much understood it.If he declines i will answer (hint: it is very easy)
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_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals