Date: Fri, 10 Apr 2026 06:59:22 +0200
> On Apr 9, 2026, at 2:55 PM, Muneem via Std-Proposals <std-proposals_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.
It was you who first said that std::tuple has bookkeeping data and thus could not be perfectly optimized. Now, that I have corrected you, you claim that you need bookkeeping data and thus std::tuple cannot work. I’m not sure if you truly understand std::tuple. It is not possible to make something more efficient than this. The compiler has everything it needs for optimal optimization. What’s missing is the right accessor.
> ****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 its 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:
C++ did not replace C. C is still around and will be as long as it is the most common denominator between a multitude of languages. Linux used to be exclusively in C (only recently has Rust been creeping in). And honestly, with the radical changes you are proposing, I’d rather wish it would be a new language and not
C++. Many languages have tried to replace C++ and some are still trying. It is not how many companies operate and it is really hard to truly replace an established language.
You are standing on the shoulder of giants if you want to change C++. And you should start to appreciate that. Contrary to what one believes in younger years, not everything is as bad as it initially sounds. There are reasons why C++ is the way it is. And some people brought a lot more experience to standardization than you do; you might not understand some of the choices, but if you ignore them you will break something important and make the the language more restricting than it needs to be.
Sometimes the best ideas come to you if you need to work within confines and restrictions. The boundaries that have been established are there to allow to do more, not less. Without the boundaries, as in your case, you are wildly imagining new things (which in itself is not bad), but at the cost that it is too specific to be useful in a multitude of problems.
C++ is quickly evolving and constantly feels like a new language (I have made the shift from not having rvalue references/std::move to C++11). And reflection will change the language dramatically again. So will profiles. You still seem uninformed about reflection: yes, template metaprogramming is a mess (because templates were never developed for that; it’s just a happy accident), but reflection is there to clean up that mess. No, you can’t really read a book about this yet because C++26 (containing the first step towards reflection) was just ratified last month. If you are proposing a new feature you need to see it in the context for C++32—you need to be informed about the features in C++29 and C++32 and that your proposed types are not possible with the extensions we will (possibly) have by then.
If you claim that reflection cannot be used, you need to understand reflection first. You also need to understand what reflection will be in the future.
>
> 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.
It was you who first said that std::tuple has bookkeeping data and thus could not be perfectly optimized. Now, that I have corrected you, you claim that you need bookkeeping data and thus std::tuple cannot work. I’m not sure if you truly understand std::tuple. It is not possible to make something more efficient than this. The compiler has everything it needs for optimal optimization. What’s missing is the right accessor.
> ****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 its 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:
C++ did not replace C. C is still around and will be as long as it is the most common denominator between a multitude of languages. Linux used to be exclusively in C (only recently has Rust been creeping in). And honestly, with the radical changes you are proposing, I’d rather wish it would be a new language and not
C++. Many languages have tried to replace C++ and some are still trying. It is not how many companies operate and it is really hard to truly replace an established language.
You are standing on the shoulder of giants if you want to change C++. And you should start to appreciate that. Contrary to what one believes in younger years, not everything is as bad as it initially sounds. There are reasons why C++ is the way it is. And some people brought a lot more experience to standardization than you do; you might not understand some of the choices, but if you ignore them you will break something important and make the the language more restricting than it needs to be.
Sometimes the best ideas come to you if you need to work within confines and restrictions. The boundaries that have been established are there to allow to do more, not less. Without the boundaries, as in your case, you are wildly imagining new things (which in itself is not bad), but at the cost that it is too specific to be useful in a multitude of problems.
C++ is quickly evolving and constantly feels like a new language (I have made the shift from not having rvalue references/std::move to C++11). And reflection will change the language dramatically again. So will profiles. You still seem uninformed about reflection: yes, template metaprogramming is a mess (because templates were never developed for that; it’s just a happy accident), but reflection is there to clean up that mess. No, you can’t really read a book about this yet because C++26 (containing the first step towards reflection) was just ratified last month. If you are proposing a new feature you need to see it in the context for C++32—you need to be informed about the features in C++29 and C++32 and that your proposed types are not possible with the extensions we will (possibly) have by then.
If you claim that reflection cannot be used, you need to understand reflection first. You also need to understand what reflection will be in the future.
Received on 2026-04-10 04:59:36