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@lists.isocpp.org> 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@gmail.com> wrote:

> On Apr 10, 2026, at 5:03 AM, Muneem via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals