On Fri, 2 Aug 2024, 07:21 Gašper Ažman via Std-Proposals, <
std-proposals_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.
>

I brought up separate compilation right at the start of the thread, and
it's been ignored repeatedly. Most of the claims for what's possible with
this proposal require whole program analysis. It's a non-starter.


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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>