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
>