Link to my code in a online editor (in case you are on your phone):
https://onlinegdb.com/MSTUxx0mk

On Thu, 9 Apr 2026, 5:54 pm Muneem, <itfllow123_at_[hidden]> wrote:

> That's the whole point, tuple dosent keep any book keeping data, it has
> always been a fun little wierd variadic template struct inheriting from
> itself, but you don't want that for book keeping Information, and you can't
> change that without breaking ABI's. To truly optimize without breaking
> ABI's you need newer mechanics, like you can't optimize a std::list without
> introducing std::vector.
> ****Some philosophical analogy(sorry if it's too abstract and personal)****
> About the Mr.herb, my answer is that languages change and they must, and
> we should not allow a few people to force us to build vertically.
> Personally, I have roots in Afghanistan and Soviets always tried to
> completely eradicate villages because they saw them as horizontal
> resistance that keeps on growing exponentially in every direction. The same
> guys, loved, protected, and heavily developed Afghan urban centers and
> infrustructure. At the end the horizontal resistance won. The point is that
> if you have a language that's not willing to grow out of it's pre existing
> philosophies someone will replace it. Look at C, C++ replaced C. Nothing
> lives for ever unless it gives rebirth to something else, c++ has been
> doing it for years, but is stopping now.The main reason for this proposal
> was that you can't fix everything with metaprogramming techniques, like the
> sky has a limit unlike what most say:
> ***How my *container would feel like* ***:
> #include <type_traits>
> #include <string>
> #include <utility>
>
> struct false_t {};
> struct true_t {};
>
> template<typename T, typename... Tail>
> struct Is_t_in_set;
>
> template<typename T, typename Head_t, typename... Tail>
> struct Is_t_in_set<T, Head_t, Tail...> {
> using boolean = std::conditional_t<
> std::is_same_v<T, Head_t>,
> true_t,
> typename Is_t_in_set<T, Tail...>::boolean
> >;
> };
>
> template<typename T, typename Head_t>
> struct Is_t_in_set<T, Head_t> {
> using boolean = std::conditional_t<
> std::is_same_v<T, Head_t>, true_t, false_t
> >;
> };
>
> struct empty_t {};
>
> template<typename T>
> struct Alias_type {
> using Type = T;
> };
>
> template<typename T>
> using Alias_type_t = typename Alias_type<T>::Type;
>
> template<typename... Args> struct N_type_unique_set;
>
> template<typename Head_t, typename... Tail>
> struct N_type_unique_set<Head_t, Tail...>
> : std::conditional_t<
> std::is_same_v<typename Is_t_in_set<Head_t, Tail...>::boolean,
> true_t>,
> empty_t,
> Alias_type<Head_t>
> >, N_type_unique_set<Tail...>
> {};
>
> template<typename Head_t>
> struct N_type_unique_set<Head_t> : Alias_type<Head_t> {};
>
> template <std::size_t N, typename... _Types>
> struct Element_t;
>
> template <std::size_t N, typename Head_t, typename... Tail>
> struct Element_t<N, Head_t, Tail...> {
> std::size_t tag;
> union {
> struct {
> Head_t* reference;
> } head;
> Element_t<N - 1, Tail...> tail;
> };
>
> inline Element_t(Head_t& a) : tag{N} {
> head.reference = &a;
> }
>
> template<typename T>
> inline Element_t(T&& a) : tail{ std::forward<T>(a) } {
> tag = tail.tag;
> }
>
> template<typename Func_t, typename T>
> inline void dispatch(T&& a) {
> if (tag == N) {
> Func_t{}(*head.reference, std::forward<T>(a));
> } else {
> tail.template dispatch<Func_t>(std::forward<T>(a));
> }
> }
>
> inline Head_t& operator=(Head_t& a) {
> if (tag == N) {
> *head.reference = a;
> return *head.reference;
> } else {
> throw std::string{"Assignment type mismatch"};
> }
> }
>
> inline Head_t& operator=(Head_t&& a) {
> if (tag == N) {
> *head.reference = std::move(a);
> return *head.reference;
> } else {
> throw std::string{"Assignment type mismatch"};
> }
> }
> };
>
> template <typename Head_t>
> struct Element_t<0, Head_t> {
> std::size_t tag;
> union {
> struct {
> Head_t* reference;
> } head;
> };
>
> inline Element_t(Head_t& a) : tag{0} {
> head.reference = &a;
> }
>
> template<typename Func_t, typename T>
> inline void dispatch(T&& a) {
> if (tag == 0) {
> Func_t{}(*head.reference, std::forward<T>(a));
> }
> }
> };
>
> template <std::size_t N, typename... _Types>
> class heterogeneous_list;
>
> template <std::size_t N, typename Head_t, typename... Tail>
> class heterogeneous_list<N, Head_t, Tail...> : public heterogeneous_list<N
> - 1, Tail...> {
> Head_t Element;
> public:
> using type_set = Element_t<N, Head_t, Tail...>;
>
> type_set operator[](std::size_t index) {
> if (index == N) {
> return type_set(Element);
> } else if constexpr (N > 0) {
> return heterogeneous_list<N - 1, Tail...>::operator[](index);
> } else {
> throw std::string{"out of bound access"};
> }
> }
> };
>
> template <typename Head_t>
> class heterogeneous_list<0, Head_t> {
> Head_t Element;
> public:
> using type_set = Element_t<0, Head_t>;
>
> type_set operator[](std::size_t index) {
> if (index == 0) {
> return type_set(Element);
> } else {
> throw std::string{"out of bound access"};
> }
> }
> };
>
>
>
>
>
> The main point is that decentralized features always win because each
> focuses on one, right now, we are using metaprogramming for everything and
> it's a mess! (Look above!!)
>
> On Wed, 8 Apr 2026, 9:52 pm Simon Schröder via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> > On Apr 8, 2026, at 9:47 AM, Muneem <itfllow123_at_[hidden]> wrote:
>> >
>> > int^ x = {1,2.5,”C++”}.select(2); This would throw a huge error at
>> compile time and is exactly why we need a new expression type T^. Not using
>> T^ would give too much freedom that could backfire as shown in the example.
>> In fact for T^, you cant even assign float^ to an int^.
>>
>> May bad, I wasn’t clear enough with my example. I do understand that with
>> index=2 the compiler should use the compile time version and return the
>> correct type. What my question actually is what would happen if the index
>> is a runtime index that happens to be 2. How would the code be compiled to
>> handle this case? What would happen to following source code lines that use
>> ‘x’? Or would you just throw an exception?
>>
>> Concerning reflection: We are not there yet with C++26. But, the ultimate
>> goal is to be able to generate arbitrary code. And we will be able to read
>> in entire functions, analyze them and then replace the function with a new
>> one generated with reflection. (With C++26 we can only analyze classes and
>> generate new ones based on this.) In my opinion, everything you say the
>> compiler should generate for your type, reflection will be able to generate
>> in one of the two next C++ versions. You should really learn about
>> reflection; maybe watch one of Herb Sutter’s talk from last year. You’d be
>> surprised what reflection can actually do right now.
>>
>> And you don’t give compilers enough credit which things they can plainly
>> see through and optimize. std::tuple does not have any bookkeeping data: It
>> just stores the elements of a heterogeneous list. The types stored inside
>> the tuple are part of the tuple’s type itself and thus part of the function
>> signature. You cannot store less data than this. There is no type possible
>> which is more efficient than std::tuple. Note that std::tuple is not at all
>> comparable to std::vector<std::variant>. Your proposed type sounds a lot
>> more like std::vector<std::variant>. Even if it is a new type, as long as
>> it is more like a vector of variants it will necessarily be slower than a
>> std::tuple because your new type would include some bookkeeping (and
>> std::tuple does not).
>>
>> I can assure your that std::tuple is already the most performant type
>> possible for your heterogeneous list (unless you want a runtime resizable
>> heterogeneous list—which is not necessary for your Turing virtual machine).
>> The only thing left is how to get elements out of the std::tuple at runtime
>> and what type should be used here.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>