czw., 1 sie 2024 o 01:42 organicoman via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Can anyone read the example at the end of the proposal, then read its explanation, check it against the rules set by the proposal and see if there are any contradictions?
>

Yes, we can and already first post have contradiction:

>> Otherwise we get overload ambiguity,
>> This is a proof that the template arguments participates in the function type.

This is false, templates parameters are used for determining only what
functions are eliminated from the overload set.
This means adding `&f<Args...>` could cause the overload set to be
empty, or have multiple candidates, in enthier
cases getting address will fail.

>> using f_type = effective_decltype (m_fun);
>> using T = extract_1st_template_type<f_type>;
>> return std::any_cast<T>( m_fun(void) );

You confuse runtime with compile time properties, you expect not
template code to magically become template like code.
Your next iterations of this idea do not fix it, only try to bury it
deeper to confuse readers that this problem does not exist.

>> Also, important to notice, is that vector is constexpr vector even we didn't explicity wrote it.

if vector is constexpr then the whole point of "type erasure" is
pointless. Type erasure is useful only
in runtime not compile time as during compilation you can easily
manipulate types.

In other your email:

>>
>> For example:
>> ----
>> template<int t>
>> int F(int x)
>> { return ( t * x ) + 1; }
>> ----
>> From this function template, it is clear that the non type template parameter, is participating in the machine code instantiated from the template.
>> So it is an important peace of information, useful to reason about the machine code of any function created from that template.
>>
>> Now, if i want to automate my reasoning about the behavior of that code, i need a way to extract that information back ( the t above) but with the current C++ there is no way to trace back to it.
>>
>> So this motivates me, to find a way to gain access to that information.
>>
>> That's the main motivation.

This is not motivation, and is not "reasoning" ethier. What exactly
does `t` give you? What exact problem will be solved?

>>
>> 1- reflection:
>> Knowing that the current implementation of any reflection algorithm, must use some static text to store information about RTTI.
>> That's not safe!
>> Because we are already storing pointers to functions in our data, which breaks the ASLR safety mechanism , then adding text that can help decompile the code, is definitely not safe.
>> So i found that, if I abuse my operator, and tweak the compiler, i can port reflection from runtime to compile time, and erase any static text in my binary in favore of generating more code.

We are talking about C++ right? Do you know that C++ reflection is
compile time ONLY?

>> 2- type manipulation:
>> Again by abusing the operator, i can simulate type manipulation at compile time.
>> For example i can abuse it to create a stack of types, where i can push and pop types, then freeze all when generating machine code.

Do you know that this is possible in C++11? I even once implemented a
simple Universal Turing Machine using variadic templates for fun.



You do not have any idea what C++ is and all your proposals are like
hallucinations generated by ChatGPT.

>
>
> Sent from my Galaxy
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals