And also unimplementable...
But you don't have to take my word for it, you can try it yourself.But ... that's the whole purpose of this thread.Putting down an idea in form of a paper, or an algorithm and tackle any contradiction it raise untill we hit the wall or we make it through.And we have just started agreeing about the core idea. Which isAdding an operator that does overload dispatch and code generation...etcIf it is not implementable, then point where, i will work on it...


From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of organicoman via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, August 2, 2024 9:15:36 PM
To: organicoman via Std-Proposals <std-proposals_at_[hidden]>
Cc: organicoman <organicoman_at_[hidden]>
Subject: Re: [std-proposals] Function overload set type information loss


Hello Gašper,
Since participants are starting to get what I am talking about, then allow me to answer your pending question.
This is what you've said in previous post.


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.


When i was describing my algorithm, i left a big X mark, hoping that someone will ask me, if people were attentive.
Line:
4-b-
    switch
    *.....
    * inside function body: goto X


Then I left a hint at the bottom of the post in a form of code comment



double var2 = *reinterpret_cast<double*>
((reinterpret_cast<char*>(&(useType()))+sizeof(int));
// int since __X_index is int. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^


The __X_index is not of type
int but of type
void*, the unnamed struct that the compiler generate becomes:

struct __Xidfc_foo_eff
{
   void* __X_index;
   union
   { int __Xi; double __Xd ; float __Xf; char __Xc };
};


Since the compiler tagged
useType function, as described by the algorithm, then after finishing recording the orthogonal template parameters, it replaces the body with the following.



auto useType(effdecltype(foo)  f) 
{ 
  f();
  switch(f)
  {
     case &f<int>: //<- the pointer value
     return __Xidfc_foo_eff{(void*) &f<int>, int(0)};



case &f<double>:
     return __Xidfc_foo_eff{(void*) &f<double>, double(0)};



case &f<float>:
     return __Xidfc_foo_eff{(void*) &f<float>, float(0)};



case &f<char>:
     return __Xidfc_foo_eff{(void*) &f<char>, char(0)};



  }
}


Pointers are comparable for equality.


As you can see, you can capture the xunion.... right? There is no fundamental misunderstanding ...
Plus everything is done by the compiler, there is no global map, no find algorithm, no type hashs, no type erasure (heap allocation), no manual intervention. All is automated at compile-time.