1.I wrote "OOP object oriented programming" by mistake.
2. Thank you for trying to help me, I really really appreciate it.
3. I agree that no language changes are needed hence I agreed with Mr.Simon
that the implementation would support the use of std::optional<T&>
std::variant<T&...> . There has been talk on this in the past, and I think
that for runtime indexed tuples, this is the least radical short solution.

I am planning to reading clang documentation this year, along with a math
book, before finally reading the whole ISO cpp draft. As of now my
information comes from fundamentals from bjarne Stroustrup's, a few other
books, and ofcourse the classic cheat sheat that everyone loves:
cppreference. The issue with terms is that the standard dosent define each
and every single one of them exactly, so even when I try to find specific
computer science keywords to find their meaning in the context of c++, I
can't. The closest I get is to use methametical terms like "closed set"
union or "open set" union. Again, I am sorry, but I trying to work on
this. Again thanks for trying to help.


On Sat, 11 Apr 2026, 10:23 pm David Brown, <david.brown_at_[hidden]> wrote:

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