Thanks for the sizeof...(Type...) Tip!
While you are exceptionally goated and up to that, there are issues with
your code that are understandable since it's a metaprogramming mess that
would make anyone do mistakes:
All you are doing is naming functions and indexing based of names, like how
is that relevant to dynamic typing? My attempt was to reinvent a type safe
version of std variant, whole your one does not only have the overhead of
std any, but also seems to be using it the wrong way like shouldn't the
member "impl_" be bound to functions in the "functions_" for invoke() to
work? Again I didn't reinvent std variant, I reinvented type safe version
of it that dosent have the original baggage. My code was to show that
without language support, you will end up writing messy code. Also say that
your version dosent need to use any_cast every time you run call() through
the facilities in reflectors to get metadata and other functions to get
functions that call members of the underlying object of "impl_" once you
any_casted it(std bind), even then you haven't fixed the issue of letting
the implementation have newer mechanics best for that specific
implementation. The goal is to have new mechanics not older ones wrapped in
syntaxtical sugar.
On Fri, 10 Apr 2026, 12:01 pm Robin Savonen Söderholm via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> I have found it quite difficult to understand what your end-goal is.. But
> if it is runtime dynamic typing, I would say reflection most likely could
> solve your problem with a caveat that dynamically calling functions may
> only be possible using `dynamic-type` as arguments. I can see an
> implementation that maybe looks like this:
> ```c++
> class dynamic_type /*or maybe just an extension to std::any/*
> {
> std::any impl_;
> struct function_key_t {
> std::string_view name;
> std::size_t argument_count;
> };
> /*map-like<function_key_t, type-erased-function-ptr>*/ functions_;
> public:
> constexpr explicit(false) dynamic_type(std::convertible_to<std::any>
> auto&& arg)
> : impl_(std::forward...(arg)), functions_(/*use reflection to store
> meta-data for all member functions of std::remove_cvref_t<decltype(arg)>*/)
> {}
> constexpr std::optional<dynamic_type> call(std::string_view
> function_name, std::convertible_to<std::any> auto&&... args) {
> if (auto it = functions_.find(function_key_t{.name = function_name,
> .argument_count = sizeof...(args)}); it != functions_.end()) {
> return
> std::invoke(reinterpret_cast</*function-pointer-that-returns-dynamic_type-and-takes-sizeof...(args)-dynamic-type-arguments*/>(it->second),
> args...);
> }
> return std::nullopt;
> }
> };
> ```
> The code is a very rough prototype, but something that I think is within
> reach of C++-26 reflections (and I think that all missing details are
> implementable as well). It would allow code that looks like this:
> ```
> dynamic_type var1 = foo();
> dynamic_type res = var1.call("bar", 5, "a c-string argument");
> ```
> .
> But I don't know why you would want something like this, and it is
> definitely not faster than e.g. std::variant or even a plain-ol'
> inheritance scheme. `dynamic_types` might even be considered a bad
> direction as it could be seen as undermining rather than improving 'safety'
> as the strict type system is there to _help_ you code better.
>
> And C++ _do_ prefer to put the majority of new features in libraries. It
> very much has the philosophy that `stl` should provide a good reference
> implementation for things often needed by programmers, but with a language
> that allows the user to make their own implementation if the standard does
> not fit the need. (I have heard of people that have several versions of
> e.g. std::vector, each specialised for a niche use-case). And if a
> large-but-not-super-generic feature can't be created as a library today, we
> still prefer to extend the language with the bare-minimum generic
> constructs that allows us to create the aforementioned feature.
>
> And I also get confused as you talk about dynamic-types, then post code
> that looks like a home-made implementation of `std::variant` (judging by
> the 'union' of 'tail' and 'head' combined with the index). A tip: since you
> are already using a 'impl' base-class, you can remove the size-parameter to
> `heterogeneuos_list` and deduce it by using `sizeof...(Types_)`.
>
> // Robin
>
> On Fri, Apr 10, 2026, 07:47 Muneem via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> I feel like you misunderstand the complexities of (strict) dynamic
>> typing, like seriously, strict dynamic typing is not duck typing(variants)
>> or metaprogramming(templates and reflectors). We keep on going in circles
>> without realizing that what I am proposing so a strict dynamically typed
>> systemed built separately. C++ philosophy is quite the opposite of building
>> everything into the library. Like compare the language features of c++ to
>> any other language. C++ language features always grew and should grow or
>> else others will take over. Dynamic typing is something that every
>> programmer has to deal with and no everyone can make a "arethimetic engine"
>> in 2 months and spend another 3 debugging and optimizing it(by measuring
>> and figuring out) . People need a language level construct for domains that
>> are completely new, and dynamic typing is a completely new domain.
>>
>> On Fri, 10 Apr 2026, 10:38 am Simon Schröder, <
>> dr.simon.schroeder_at_[hidden]> wrote:
>>
>>>
>>>
>>> > On Apr 10, 2026, at 5:03 AM, Muneem via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>> >
>>> > It dosent have to cook with water, like it's a new feature.
>>> “Cooking with water” is a metaphor for that your proposal still needs to
>>> use the same compiler, the same optimization techniques, and the same
>>> hardware. As long as the hardware doesn’t change both your new type and all
>>> existing types have the same CPU instructions available. And honestly, the
>>> easier the code you write the easier it is for the compiler to optimize.
>>> More different optimization strategies will not fit into the time budget
>>> that compiler writers put into compilers.
>>>
>>>
>>> > And the library can't achieve the same thing without breaking existing
>>> code, like how are you gonna let the compiler optimizes a variant for std
>>> visit without expecting code expecting a normal variant to not work.
>>> I still fail to see any optimizations you are proposing that would not
>>> work for existing uses of std::variant. Wouldn’t all uses of std::variant
>>> benefit from the optimizations that you propose? Your new type is in
>>> general terms still a union/variant/tagged enum. In theory, it can be used
>>> in all places a std::variant can be used. How do you teach when to use
>>> what? If in the end your new type would effectively replace std::variant,
>>> we really should be changing std::variant (at least it is a good name and
>>> it’s better to reuse it than to invent a new awkward name). Yes, we hate
>>> breaking ABI. But, it has happened with std::string on GCC before (and MSVC
>>> used to constantly break ABI with every new version). ABI changes usually
>>> don’t break code, but only linking with existing libraries. If there is a
>>> good reason (and if it happens rarely) we should break ABIs.
>>>
>>> > The solution is a new construct. Like how can you say that the gain is
>>> non existent. It's like I can write something similiar to template
>>> metaprogramming patterns using macros but should I? Will that be better?
>>> The standard prefers library solutions over new constructs. If with
>>> minor changes to the language we can make your proposal work as a library,
>>> this is the preferred route. Built-in types should not have any special
>>> privileges in C++. A user-defined type should have all the privileges of a
>>> built-in type (this is why we have operator overloading). If we adhere to
>>> this principle, your new type should be implementable as a library type. If
>>> you don’t like this philosophy of C++, choose a different language.
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>