On Thu, 1 Aug 2024 at 09:48, organicoman via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
>
> We can only do step 2 if we have a working compiler. Since we don't, we
> can't
> use the steps above.
>
> We have to replace the step of "use" with the rules and the rules are too
> vague at this point.
>
> That's a honest and direct question. I like this way of discussion,
>
> Instead of attacking the proposal by downgrading the understanding of its
> writer, like some do, It is preferable to say "i don't see this coner,
> can you enlighten me"...no shame.
>
> I'm still waiting for motivation and use-cases.
>
> Alright,
> The core dea, is to keep all meaningful information that participated in
> generating machine code.
>
> 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.
>
> On the other hand, millions lines of code rely on the current behavior of
> C++.
> So if i try to add that information to the type system, for sure it will
> break all code.
> Also, since many peace of code seems to work without the need of that
> information (either by choice or by obligation), it denote that it is
> optional.
>
> A rigorous solution should take the above in consideration.
>
> That's the core of the proposal.
>
> The way to implement it is an exercise to the reader, each and everyone
> has a different approach.
>
> ---- one way of implementing the motivation-----
>
> My approach, is to add an operator called effdecltype (the name is not
> important)
>

If the name is not important, I suggest you pick another one immediately.
This is not the "type" of the function, and it's certainly not the
"effective type" of the function. Calling it "effective type" makes it
sound like "the type that it effectively has" which is ... its type. The
types of F<1> and F<2> are effectively the same, because they *are* the
same. The effects of calling them are not the same, but "effective" in
English has a particular meaning which makes "effective type" very
misleading, and doesn't help you to explain your idea.

Call it a meta-type, or a cthonic type, or a typeform (the part of a
printing press that holds the type) or anything else.




> This operator must have some properties.
>
> One property is that : it can replace the operator decltype without
> disturbing its current meaning.
> 2nd property is that: it can trigger the desired behavior when applied to
> 3 types only and on demand : arrays, instance of function templates,
> instance of variable templates
>
> ----- end of my approach ------
>
> While researching to implement the above, I stambled on other motivations
> that were not considered at all.
>
> *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.
>
> *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.
>
> ...and so on, the possibility are considerable.
>
> I was trying to solve some problem, i found solutions to unrelated
> problems.
>
> *Implementation wise:*
> The scope of the operator above is well defined.
> Arrays, instances of function templates and instances of variable
> templates.
> So it is feasible to reason about the code using them, and build a
> compilation planner that can prove then pick the right technique to
> generate code.
>
> In my example, at the end of the paper, i *abused* the operator to store
> types in a container and fetch them in a loop.
> So from compiler stand point, there are two case figure.
> Either the compiler can see what was pushed to that container, or it is
> unpredictable to do so.
> Two solutions are plausible.
> 1- replace the stored instance of the global value with some key, then add
> a hash map:
> Key<->function, no need to predict any thing.
>
> 2- unroll the loop if we can prove that we have all elements of the
> container available and it is efficient to do so.
>
> Again, this is abusing the operator's behavior from its main purpose.
> Yet, it is useful and feasible.
>
> Thiago,
> I hope i answered your question?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>