My response to Mr.Davis Brown is that:
1. Sorry for my informal discussion and usage of terms.
2. C++ is a statically typed language but OOP programming isn't a
substitute for dynamic typing, nor is duck typing using variants.
(Trying to keep my response short and professional as you recommended):
3. My solution will provide dynamic typing in three ways:
1. A type that acts like a std::variant<T&...> But is a language level
construct since allowing a variant like that changes a pre existing concept
and constraints it within the interface provided for the common utility of
that concept. That type would be
A new expression value type:
Type_set<T...>
Type_set can basically have any type but once the type is set at runtime,
it can't change
2. A new type T^ that Type_set<T...> Decays into when ever it is used for
the current T that it holds. This simplified the rules of overload
resolution because T^ itself does not decay into anything if the overload
for T^ is provided. If not provided then the Hirearchy is:
For T^:
Const T^
T
Const T
T&
Const T&
For Const T^:
Const T
Const T&
To move the underlying value of T^, you can move it using std::move().
3. Is a new container std:: heterogeneous_list<T&...> Where the
::value_type is type_set<T&...> . The type of each index is known at
compile time (using constexpr to make the type of each type_set<T&...> In
the container known at compile time.
The usage of all things would look like:
Std:: heterogeneous_list<int, float> obj;
Type_set<int, float> element= obj[runtime index];
And of course, you could write:
Decltype(obj)::value_tyoe element= obj[runtime index];
Passing element to a function will cause the compiler to generate branches
that basically figure out what T is in type_set<T...> At runtime. Based of
what T is in runtime, the element is decayed into T^ for that T, and then
the relevant overload for T^ or the decayed T^ is run. The overloads for
each T^ are ofcourse figured out in compile time, but branching to find the
current T so you could run the relevant overload is done at runtime.




On Fri, 10 Apr 2026, 7:24 pm David Brown, <david.brown_at_[hidden]> wrote:

>
> On 10/04/2026 13:34, Muneem via Std-Proposals wrote:
> > Why do we need to go in circles? Like std::variant is a union hence not
> > STRICTLY DYNAMICALLY TYPED. It's like you would use an array of variants
> > or rather use a tuple of the same types, the answer is the former if the
> > goal is complete duck typing over a closed set, and the latter if you
> > want fixed types at fixed indexes. Both work well for their job.
> > Similarly you need new types for strict dynamic typing. All three
> > concepts are their own domains: strict dynamic typing(my proposal), open
> > set duck typing(variant), and strict static typing(tuples).
> >
>
> The reason we are going around in circles, as far as I can see, is that
> you have been unable to express your thoughts in a clear manner, using
> standard terms. You have sent hundreds of messages to this list in the
> last few weeks and I still think most people have no idea what you are
> trying to achieve. It does not help when you use technical terms in a
> nonsensical (or at least non-standard) manner.
>
> Let's get back to the basics, in an attempt to find common ground.
>
> C++ is, at heart, a statically typed language. That means at any point
> in the code, the compiler knows the type of any given variable. It also
> supports a kind of dynamic typing through class inheritance. In this
> case, the code might have a pointer "p" that points to an instance of
> class T or any descendants of T - the function using "p" can then be
> used directly with many types, as long as they are descendants of T.
>
> std::variant<A, B, C> can also be viewed as a limited kind of dynamic
> typing, in that the type held by an instance "v" can be changed at
> run-time between A, B and C. But it can also be viewed as a static type
> which is the "sum" or union of types A, B and C. It is not a dynamic
> type in the sense found in a language like Python, because your code
> must first identify which of the fixed set of types the variant instance
> holds before you can do anything with it - you have a dynamic check
> followed by static dispatch, not dynamic dispatch.
>
> Orthogonal to the static/dynamic choices for a type system, there is
> also the distinction between nominal and structural typing.
> Fundamentally, C++ using nominal typing - an instance "x" is of type "T"
> because it is declared to be of type "T", or because it is declared to
> be of type "S" where "S" is declared to inherit from "T". This is
> different from structural typing, where type compatibility is based on
> the structure and features of the type, not declared relationships.
> ("Duck typing" is basically just dynamic structural typing.)
>
> C++ supports structural typing for templates and concepts - which are
> strictly static compile-time features, not dynamic typing.
>
>
> It is not a good idea to use the word "strict" when talking about types,
> because it sounds like you are talking about strong type checking, and
> it is often mixed with static typing. Strong vs. weak is just a matter
> of how much checking you have at compile-time (for static typing) or
> run-time (for dynamic typing) of types, and how much you can mess around
> with them in the code - weak typing can sometimes mean less effort in
> writing code (compare Javascript or PHP to C++) or more efficient
> results (compare void* to std::any, or union to std::variant<>), while
> strong typing is better for catching errors in the code.
>
>
> Now, let's look at what you wrote:
>
> "std::variant is a union hence not STRICTLY DYNAMICALLY TYPED"
>
> That makes little sense. A std::variant is a /tagged/ union - it is a
> strongly typed, static sum type. (A "sum type" means roughly that the
> std::variant<A, B, C> supports all instances of A plus all instances of
> B plus all instances of C.) It does not support dynamic dispatch -
> though you can use the visitor / overload pattern to look like that.
> And it is strongly (or "strictly") typed. Other names for this concept
> in other programming languages include "discriminated type" (Ada),
> "variant records" (Pascal), "enum" (Rust), "choice" (Circle), "sum
> types" (Haskell).
>
> A std::tuple<> is completely different. Basically, that is a simple
> struct with a shorted declaration that does not name the fields. It is,
> in type theory terms, a product type - a std::tuple<A, B, C> contains an
> instance of all three types at the same time. It is also strongly typed
> and static.
>
> You use std::variant<A, B, C> if you want to have /either/ an A, /or/ a
> B, /or/ a C, and you use std::tuple<A, B, C> if you want to have /all/
> of an A, /and/ a B /and/ a C. std::tuple<Car, Bike> describes the two
> vehicles you have in your garage, std::variant<Car, Bike> describes the
> single vehicle you take to the shop.
>
> Your decision as to which to use has nothing to do with "duck typing"
> (whatever you think that means) or "fixed types at fixed indexes"
> (whatever that is supposed to mean). And both of these types are static
> types, formed from a closed set of specified types. Neither is "open" -
> you cannot add new subtypes into the type once it is defined. (This is
> different from polymorphism via class inheritance, which is the only
> dynamic typing in C++.)
>
>
> It is impossible for anyone to understand your "proposal" for "strict
> dynamic typing" or "extension to runtime polymorphism" when you defining
> it in contrast to "open set duck typing variant" and "strict static
> typing tuples" while apparently not understanding any of those terms or
> the C++ types. Oh, and C++ already supports "strict dynamic typing" -
> that's the whole point of inheritance, virtual methods, and dynamic_cast<>.
>
>
>
> As I see it, you have a couple of options. You could learn some
> computer science and type theory - or at least read the relevant
> Wikipedia articles. Or you should simply stop using terms like static
> typing, dynamic typing, and anything related. And read the
> cppreference.com entries on std::variant<> and std::tuple<>.
>
> Simply write a short example of the code you would like to be able to
> write, using your new language features. If it is more than about 20
> lines long, scrap it and start again. Then write an explanation saying
> why you think this is beneficial to the language - say what you think it
> expresses in a clearer way than could be done without your change. Tell
> us how it makes it easier for normal users to write correct code, or how
> it makes it harder for them to write incorrect code by mistake, in
> comparison to the existing language. (It doesn't much matter how
> difficult things are for expert library implementers - it's ordinary
> users that count.) Tell us how often such code would be useful.
>
> Give the post a new title for a new thread on the mailing list. Save it
> as a draft.
>
> Wait an hour, then go back to the draft. Re-read it, and edit it as
> necessary. Save the draft again.
>
> Have another round of editing, with an emphasis on clear layout and
> formatting with plenty of space, and accurate grammar and spelling.
> Remove all teenage chatter - many on this list have grey beards, but
> none of us are "goats". And we are not interested in your sleep
> patterns - this is a technical mailing list for discussing C++ standard
> proposals.
>
> Do not post until you are confident that your post says what you want it
> to say, in a clear and unambiguous manner. Replies to your own posts
> should be extremely rare.
>
> When you later reply to others, please use standard conventions for a
> list like this. Occasionally a short top-post reply makes sense, but
> generally replies answering comments or questions should come /after/
> those comments, so that the entire post makes sense when read from top
> to bottom, and it is clear who wrote what. Do not copy bits of a
> poster's questions and add random formatting - put your answer to the
> question after the original question.
>
>
>
> You clearly have a lot of enthusiasm, and given the effort you have made
> in all your posts so far, you obviously feel you have something
> important to contribute to C++. That is all great. But you need to do
> much better at communicating it, or else we are all just wasting our time.
>
>
>
>