The syntax would be one of the last things to consider.Much more important is, what kind of thing you are talking of, what operations are possible, why it cannot be done with current C++The current standard deliberately drops on purpose any extra information under the pretext of pointer decay.Are the origin template parameters part of a new (more complex) type? Would more code be templated?Or is it a powerful form of reflection without any change to the type system? But the compiler goes back to the assignment, if possible? That is the base decision on, what you are actually proposing.Depending on it, we could know, whether this information is transferred into functions through their parameters. As always, great questions 👍 As i said earlier, the infrastructure is already implemented in the compiler, it is just ignored and not transferred.When you dotemplate<typename T> int globalVar = 123;auto var = globalVar<double>;At this location, you stamp out an effective type attached to var, wherever you use that var, it will be available for access.At one condition, any function that needs to preserve that effective type, it must declare its argument as auto (perfect forwarding), otherwise the effective type will be lost inside an implicit casting operation Example:void loseEffectiveType(int arg); // cast to intvoid keepEffectiveType(auto arg); // preservedInside the function body, loseEffectivrType , the operator effective_decltype(arg) will return int;And inside the function body keepEffectiveType, the operatoreffective_decltype(arg) will be (int)<T> where T is resolved when called.Any other questions?-----Ursprüngliche Nachricht-----Von: organicoman via Std-Proposals <std-proposals_at_[hidden]>Gesendet: Di 30.07.2024 17:06Betreff: Re: [std-proposals] Function overload set type information lossAn: Jonathan Wakely <cxx_at_[hidden]>; CC: organicoman <organicoman_at_[hidden]>; std-proposals_at_[hidden]; body { font-family: monospace; } But what is '<int>(double)'? That's not a thing that can be represented in C++ today. It's not a type, so you're inventing an entire new category of "thing" in the language. Correct, it is not a correct C++ syntax.And yes, it is an invent new thing You need a *much* more complete proposal for such a thing, explaining how it works, how to use it, and why it would be different from a meta object proposed by the Reflection papers. I was looking at Clang implementation of variable templates, the infrastructure to implement the above is there, but seriously to add parsing of such syntax is not trivial.So a decision should be taken, to either make that syntax and internal compiler idiom, and let the user only refer to it through an operator, like for example: effective_decltype()Then add some type traits to manipulate that unnamed type.Or make it a concrete syntax.I hope that one of compilers implementers would adopt the idea.As for its usefulness, it is as good as meta object, with the benefits of using compile time meta programming, since we are dealing with types directly.