Look I'm not calling out of in order to try and gate keep you. Or to put you down.
But I can tell, it's not a lot.
There's no shame of being new to the language, we have all been there.
I was a noob once to, and let me tell I had some weird misconceptions about the language to.

But unfortunately, this is a standards definition, everybody who has ever written C++ as to deal with stuff that's in the standards. And this includes very smart people, with a life time and legacy of experience. It includes many such people.
And I have seen many such smart people fail to put a dent into a new proposal.

It is building upon the work of many people that came before. If stuff was this easy, odds are there would been many opportunities for people in the past to have picked it up and do it already. The consequence of this is that as time progresses, whatever is left that can be done gets increasingly harder.

It's far more likely that you have done a mistake, than you have stumbled into something new.

I'm not saying that it is impossible for someone with little experience to be able to put on an effective
proposal that changes something in the standard. But do too the great filter, unless you are working at the very top of the edge you are not likely to succeed.

Unfortunately, you have to be this tall to take the ride.
Technically speaking, you don't have to, but it is highly recommended.

Shit is hard! Even for an expert.



One thing that I can tell you immediately from experience is that what you are asking for is impossible to implement. It cannot be done with the C++ model, and it should never be.
This is immediately apartment by things like, not knowing what the compiler can know, naive expectations of having compile time information being deduced from runtime data, not understanding how code gets compiled, and not understanding that template parameters (even though can be described with types) they are not a description of the type being declared.

You cannot see this because you don't have the experience necessary to understand these things and why they are important.


And I have a genuine advice.

Spend more time learning the language, try to understand why things are the way they are first. Try to understand what the compiler can know and how it does what it does. It isn't a magical application made by the Gods, people like you and me have written them, and they had to figure out a mechanism to get it to work.
If people with experience tell you that it doesn't work this way, you should consider their advice.
And if you don't know the technical details on how to get this to work in practice, i.e. what is the compiler should actually do to achieve this result. You should not count on "the smart programming people to do it for you" because they are telling you "it can't be done".
And unless you have something concrete in terms "how exactly it can be done", this conversation is pointless.





________________________________
From: organicoman <organicoman_at_[hidden]>
Sent: Wednesday, July 31, 2024 10:53:26 PM
To: Tiago Freire via Std-Proposals <std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] Function overload set type information loss





Sent from my Galaxy


-------- Original message --------
From: Tiago Freire via Std-Proposals <std-proposals_at_[hidden]>
Date: 8/1/24 12:44 AM (GMT+04:00)
To: std-proposals_at_[hidden]
Cc: Tiago Freire <tmiguelf_at_hotmail.com>
Subject: Re: [std-proposals] Function overload set type information loss

Quick question, how many years of experience do you have writing code in C++ at a professional level?

Enough to know what I am doing.

Now to the meat of the discussion.
Do you have any ambiguity?




________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of organicoman via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, July 31, 2024 10:23:07 PM
To: Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Cc: organicoman <organicoman_at_[hidden]>
Subject: Re: [std-proposals] Function overload set type information loss

This is my proposal(C++17 based) hopefully somebody will rewrite it in a better standard way.
----------------------------------------------------

Operator
   effdecltype(expression)

Other plausible name : typeof (expr)

Intro
    C++ Is a type strong programming language, each object used has a well known type.
For all object instantiated/defined in a program there is a one to one mapping between the name and the type it belongs to.
Except for 3 categories:
1- Arrays
2- Function templates
3- Variable templates

Collapsing type signature into one type id, makes tracing back what was passed/called impossible. And it is an aberration to the strong typing adopted by C++ language.
Let's illustrate that with some examples:
Category 1:

#include <type_traits>
template<typename T>
void foo(T t)
{
    static_assert(std::is_same_v<T, char*>);
}
int main()
{
   char arr[5];
   foo(arr); // #1 assertion passed
   static_assert(std::is_same_v<decltype(arr),
        char[5]>); // #2 assertion passed
}

In the example above, the same variable arr has two different types
#1 char*
#2 char[5]
That's what i mean by type signature collapsing. The standard calls it array pointer decay.

Category 2:

#include<type_traits>
template<typename T>
void foo() { }

int main()
{
  auto foo_1 = &foo<int>;
  auto foo_2 = &foo<double>;
  static_assert
  (
      std::is_same_v
       <
          decltype(foo_1)
        , decltype(foo_2)
>
   ); // #1 assertion passed
}

In this example, we have two functions instances with different type signature, yet their type id is the same.

Category 3:

#include<type_traits>
template<typename T>
int Var = 123;

int main()
{
  auto var_1 = Var<double>;
  auto var_2 = Var<char>;
  static_assert
  (
    std::is_same_v
    <
      decltype(var_1)
    , decltype(var_2)
>
   ); // #1 assertion passed
}

The same as well for variable templates.
Different signature collapsed to same type id.

The standard doesn't explain why it adopted this behavior, except for the case of array pointer decay.
But from the examples above, we can observe a recurring pattern.

There are two different types, one written by the user, and one seen by the compiler.

The type written by the user is the real effective type, but the type seen by the compiler is the apparent type over the rest of the program.

Motivation
    To preserve the one to one mapping between what the user intend and what the program see, and to keep a way to trace back all calls and usage of any type, we need to solve this duality between effective type and apparent type.
Some consequences engendered from this solution, is type introspection and easy type erasure.

Discussion
    While analyzing the behavior of the examples given (category 2, category 3). We extracted the following observations:

1- if the template parameters don't participate in the apparent type of the object, a dissociation between the apparent type and the effective type is created.
Let us call this kind of template parameter an othogonal template paramter

2- All orthogonal template parameters contribute in resolving the instance's value, but don't participate in the type id.

So mathematically speaking:

let:
template<typename...Ts> U;
a templated type where:
U ∈ { category2, category3 }
let:
S(U) = {Ts...} the set of all template arguments of U.
If we prove that there is a sub set A(U) of S(U), where:
A(U) ⊆ S(U) ^ A(U) is not empty.
∀P ∈ A(U) ^ P is an othogonal template paramter.
then:
apparent type(U) is Not the same as effective type(U).

Some examples for illustration:

#include <type_traits>
template<typename T, typename V>
void foo(V v) { }

int main()
{
   auto f_ptr1= &foo<int, double>;
   auto f_ptr2= &foo<char, double>;
   static_assert(std::is_same_v<decltype(f_ptr1), decltype(f_ptr2)>); // assertion passed.
}

In the above example:
S(U) = { T, V }
A(U) = { T }

A(U) is not empty which implys that:
effective type (foo) != apparent type (foo);


Introducing operator effdecltype (or typeof)
    The purpose of this operator is to detect the case described above and record it for the concerned variable, and avoid breaking any code relying on apparent type.

Definitions
    This operator has the following properties.

Let
expr, expr1, expr2 ∈ {category1, category2, category3}

1- If:
effdecltype(expr1) same as effdecltype(expr2)
Then:
decltype(expr1) same as decltype(expr2)

2- casting
decltype(effdecltype(expr)) same as decltype(expr);
Given this property we can write directly
decltype(expr) same as effdecltype(expr)
for convenience.

3- If:
decltype(expr1) same as decltype(expr2)
And
effdecltype(expr1) not as effdecltype(expr2)
Then:
effdecltype(expr1) could be written as
decltype (expr1) <A1(U)>
And:
effdecltype(expr2) could be written as
decltype (expr2) <A2(U)>
Where:
A1(U) and A2(U) are the set of orthogonal template parameters for expr1 and expr2 respectively.

4- change of behavior for auto keyword :
auto var = effdecltype(expr);
auto var2 = expr;

auto here carries the same meta-data as effdecltype(expr), denoting perfect capturing of the effective type.

5- casting:
decltype(expr) var = effdecltype(expr){ expr};

This is an explicit cast of the effective type to an apparent type, and the var object type has no extra meta-data.

6- value comparison:
if:
effdecltype(expr1){ args } == effdecltype(expr2){ args }
then:
decltype(expr1){ args } == decltype(expr2) { args };
And the opposite is also true.
Where:
args are the arguments to the constructor of the expression's type, which are usually the expression itself.

7- fallback to decltype behavior:
If exprX is not one of the 3 categories above.
Then:
effdecltype(exprX) same as decltype(exprX)

In funny summary:
effdecltype is decltype with X-ray vision

Illustration with examples:
(If effdecltype operator is implemented)

#include <type_traits>
template<typename T, typename V>
void foo(V v) { }

template<typename X, typename Y>
auto Var = Y{123};

void
  bar(effdecltype(Var<float, short>) const& a)
{
    static_assert(std::is_same_v<short,
decltype(a)>); // assertion passed

   static_assert
   (
      std::is_same_v
      <
         effdecltype(a)
       , effdecltype(Var<double,short>)
>
    );//passed (must read comment X*)
}

template<typename X>
using meta_double = effdecltype(Var<X,double>);

int main()
{
  auto foo_1 = effdecltype(&foo<int, double>){&foo<int, double>}; //#1

  void(*foo_2)(char) = effdecltype(&foo<double, char>){ &foo<double, char>}; //#2

  auto foo_3 = &foo<long long, char>; // #3

  static_assert
  (
    std::is_same_v
    <
      decltype(foo_3)
    , effdecltype(foo_3)
>
   ); // assertion passed (read comment X*)

  auto var_1 = effdecltype(Var<char, int>){ Var<char, int>};
  int var_2 = Var<double, int>;

  if(var_1 == var_2)
    puts("different effective types, same value"); //printed

  static_assert
  (
    std::is_same_v
    <
        decltype(var_1)
       , effdecltype(var_1)
>
   ); // assertion passed (read comment X*)

   meta_double meta1 = Var<char,double>; // #4
   meta_double<float> meta2 = Var<float,double>; // #5
}

In the example above we illustrated some of the properties of operator effdecltype

In effdecltype's type notation we can write

Case#1: foo_1 is void(*)<int>(double), perfect capture with operator auto.

Case#2: foo_2 is void(*)(char), casting from effective to apparent type.

Case#3: foo_3 is void(*)<long long>(char), perfect capture with operator auto.

Case#4: meta1 is (double)<char>,
First effdecltype was applied to the right hand side of the assignement to deduce the missing orthogonal template parameter of the alias type meta_double, via template argument deduction mechanism, then the value of Var is assigned to meta1

Case#5: meta2 is (double)<float>,
Same as #4 but the othogonal template paramter was explicitly provided, if types mismatch a compiler warning is raised.
The decision to raise a warning instead of an error, is to denote that, what the user writes is what the program should adopt.

Comment X*:
Since the actual type-traits machinery relys on the apparent type to do its job, then when we use effdecltype inside any type-traits meta function the effective type is cast to the apparent type. Remember effdecltype is just decltype with X-ray vision.
Later in the this paper we will show how to fix this situation.

Usage
    After defining what the operator does, we have the opportunity, in this part, to show some usage and implications of such operator.

To use the operator effdecltype effectively, we need to add some tools to our beloved C++ language.

builtin functions:
template<typename U>
constexpr size_t __orthogonal_size__(effdecltype(U{}) = {}) noexpect;

Returns the count of orthogonal template parameters (size of A(U) defined above.)

template<typename U, typename R, size_t I>
constexpr R
__ortho_type_at__<I>(effdecltype(U{}) = {}) noexcept;

Extracts the orthogonal template parameter at index I in the set A(U) defined above.

More builtin functions can be defined, but this is what i have in mind now.

Tips and tricks:
The following is not an exhaustive list of all what we can do with this operator, but just a guid to unleash the user's imagination.

1-store and load types:

#include <vector>
template<typename T>
inline constexpr int Var= 123;

struct S{
    template<typename T>
    using meta_int = effdecltype(Var<T>);
meta_int m_val;
    template<typename T>
    constexpr S() noexcept
      : m_val (Var<T>)
    { }
};

template<typename T>
void ActBasedOnType(int val)
{
  std::cout << typeid(T).name() << "->" << val << std::endl;
}
int main()
{
  std::vector<S> vec;
  vec.push_back(S<int>{} );
  vec.push_back(S<double>{} );
  vec.push_back(S<char>{} );

  for(const auto& elem: vec)
  {
    std::cout << S.m_val << std::endl;
  } // prints: 123\n123\n123\n

  for(const auto& elem: vec)
  {
     auto data = S.s; // uses effdecltype
     ActBasedOnType<__ortho_type_at__<0>(data)>(data);
  }// prints: int->123\ndouble->123\nchar->123\n
}

So what is all this black magic??
Explanation:
Observation: You must keep in mind that the 3 categories we are dealing with are global constexpr variables. And when we assign their values to other variables we can decay it to a reference (case of function pointer) if that variable doesn't modify its value, or we stamp a copy of their values (for variable templates if copy needed).
Our interest is in the orthogonal template parameters not the value.
With this paper addition we are going to exploit that fact deeply.

The struct S above defines a templated effective type alias, captured from the global variable Var<T>.

We define also a function template which prints the type of its template argument.

Inside main we creat a vector of S.
sizeof(S) == sizeof(int) and alignof(S) == alignof(int)
Also, important to notice, is that vector is constexpr vector even we didn't explicity wrote it.
Why? Because all elements of vec are references to a global constexpr variable known at compile time and its size is known at compile time.

We push values of type S, using the templated constructor.
Since we are instantiating values of Var<T> indirectly, the compiler creates an internal table of mapping between orthogonal template parameter T and an index i in vec.

In the first "for loop", the regulare compilation process is performed. m_val is of int type no magic there.

In the second "for loop", the compiler unrolls the loop and instantiates a function out of ActBasedOnType<T> with T fetched from the internal structure created when pushing values into the vector.
So the loop will be replaced by

ActBasedOnType<int>(123);
ActBasedOnType<double>(123);
ActBasedOnType<char>(123);

The compiler has the choice to keep that inner mapping structure for latter use, and it can update the mapping if it sees necessary.
Otherwise it can destroy it if it can prove that there is no necessity to keep it.

All the magic happens in the unrolling of the loop.
Because all information are available at compile time. (Remember the green observation above.)
Unrolling the loop is one technique , other techniques could be stamping a switch statment, or implementing a visitation method.... compilers implementers are free to amaze us.

FIN.


Oh man it's tiresome on a cellphone..🥵