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. 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. In particular for std::variant<T&...>
specialization to to some std::optional<T&> at runtime, you need some
branching or some implementation support that can't be expressed in the
language, but I will still go with it, since it is what works the best. I
will start working tomorrow and hopefully complete it in 2-4 days. Thank
you for the feedback that all of you were kind enough to send, and I will
never forget you guys. If anyone is kind enough to join me in writing it
then please email me.

On Sat, Apr 11, 2026 at 4:13 PM David Brown <david.brown_at_[hidden]>
wrote:

>
> On 11/04/2026 05:30, Muneem wrote:
> > My response to Mr.Davis Brown is that:
> > 1. Sorry for my informal discussion and usage of terms.
>
> Informal language is fine - it's the teenager chat that is going too far
> (IMHO). But it is more important to use technical terms correctly, or
> not use them at all.
>
> > 2. C++ is a statically typed language but OOP programming isn't a
> > substitute for dynamic typing, nor is duck typing using variants.
>
> Again - variants are not in any sense "duck typing". Either you don't
> know what a std::variant<> is, or you don't know what "duck typing" is.
> You are getting this badly muddled, and it is making it impossible to
> figure out what you are trying to say. In the words of Wolfgang Pauli,
> you are not even wrong here.
>
> Class inheritance - presumably the aspect of OOP you are referring to
> here - provides a controlled and limited form of dynamic typing in a way
> that can work efficiently in a compiled language. Nobody thinks it is
> comparable to what you get in fully dynamic typed languages like PHP or
> Python. But if you are looking for completely dynamic typing, then you
> should be looking at different languages - not C++. There are good
> reasons that there are many programming languages around, suitable for
> different kinds of programming tasks.
>
> (Of course you can make dynamic typing within C++ - it's a Turing
> complete language after all. Another poster demonstrated this.)
>
> > (Trying to keep my response short and professional as you recommended):
>
> And yet you are still missing the point about how to reply to posts, as
> explained to you by several people.
>
> > 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.
> >
>
> You have done nothing to show what the code would actually look like.
> And nothing to explain why anyone would want it, what problem it solves,
> or why it is better than existing solutions to the same problems.
>
>
>
>