Seems like the proposal is "lift everything you might wanna do with a type
at compile-time to runtime. Which requires a JIT.

On Fri, Aug 2, 2024, 10:51 organicoman <organicoman_at_[hidden]> wrote:

>
>
> 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_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>