On 11/04/2026 13:56, Muneem wrote:
> I am really sorry about the calling variants duck typing, like I called
> it duck typing in the same way you called OOP object oriented
> programming, but I think I took it too far.

There is no comparison here. "OOP" and "object oriented programming"
are interchangeable terms, because "OOP" is an abbreviation for "object
oriented programming".

C++ std::variants<> (and similar "variant" types in other languages, if
you want to be general) are not remotely related to the concept of "duck
typing" in any way.

Your whole argument, in all your vast number of posts, has been based on
your random and completely incorrect usage of terms such as "duck
typing". We are not talking about loose or informal terminology, or
slight inaccuracies - it is utterly wrong.

Rather than apologising, you should go away and learn what you are
talking about here. Once you have read enough about static typing,
dynamic typing, duck typing, C++ variants and tuples and polymorphism
(run-time and compile-time), re-think your ideas and try to figure out
if they are still valid and useful. Then try to explain them. (I gave
you a summary of the meaning of the terms here - if that was not
sufficient for you, there are lots of other good sources around.)
Again, let me re-iterate - I want you to be able to talk about your
ideas, and if they are good ideas, I want them to be considered for
future C++. I am not trying to stop you here, I am trying to help you
express yourself more constructively.

> As for the interface, I have
> agreed (to Mr.Simon's advice) that I will simply provide a simple
> std::variant<T&...> specialization that can convert to a
> std::optional<T&> for every T at runtime, and there would also be a
> secondary specialization for tuples that is going to be runtime indexed.
> This updated proposal, however, relies on the same support as my
> previous one, but it just seems to be that the community loves to expand
> existing ideas as applications to new domains instead of inventing new
> ones.

No, it does not. Both of these things can be done in today's C++. (I
would not trust myself to get everything right for all kinds of
references, but there are many people here who are far better than I am
at that kind of thing.) It seems likely to me that it can be done in
other ways, and perhaps more efficiently, using reflection - which is
already part of the future of C++. If these features were added to the
standard library, then implementations could be made today without
changes to the language or toolchains. And if those implementations
were not as efficient as theoretically possible, toolchain vendors would
do as they usually do in such cases - add implementation-specific
features (like gcc "builtin" functions) or optimisations that can be
used by the implementation-specific standard library implementations in
order to maximise the efficiency. No language changes are needed.