Date: Wed, 8 Apr 2026 18:51:59 +0200
> 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.
>
> 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.
Received on 2026-04-08 16:52:13