Mr.brown is right that std variant isn't technically duck typing, but isnt
dynamic typing also. The issue really is that c++ while statically typed
also needs dynamic typing at some point. The only way to do so is what I
would call "Automated compiler generated dispatch code" that my proposal is
trying to get c++ to have. Such features won't change anything that already
exists but will only give support to "new paradigms of programming"/more
flexibility(with zero to no effort from the programmer) in c++.

(Sorry for sending two replies at the same time, my previous email repeated
the technically mishap of calling variants duck typing.

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.
>
>
>
>