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.