On Fri, Apr 17, 2026 at 10:48 AM Muneem via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 1. The fact that strings were improved says a lot. It proves that no user defined code is always right, and unlike the user, the standard can change your code on a large scale and actually fix it if it makes a mistake, whereas the user usually can't for large projects(even with these modern AI based tools).

It also proves that premature optimization can lead to bad things.

> 2. My point was that performance isn't straightforward, it depends on a lot of factors, hence the standard library only gives out space and runtime gurrenties. I dont want to continue defending myself on paging since I am not that much into operating systems, sorry for bringing it up (my perspective was to look at it from a larger perspective).

It isn't straightforward. It's not something that the compiler can do
for you in this instance. The tradeoff you're talking about is not
something the compiler has enough information to do on your behalf.

> 3. Again, vocabulary is important, and if you dont like to be confined within the "terms and services" of what it provides then you can always write your own. Just because you can write your own does not null the idea of the importance of vocabulary. As bjarne stroustrup puts it multiple times that you can build your own version of standard library facilities but then you will have to maintain them and document them.
> 4. Vocabulary is a magic wand because as bjarne stroustrup mentioned in his podcast with Lex friedmen: there was a guy who compared C and C++ code, the C++ code was way shorter than the C code(which kept on expanding). Again, the user generally dosent know much about what's best, hence in 99 percent of the cases, he wants the standard to take over, but in some cases, he might want himself to do the task. The point is that we have an infrastructure that can provide mechanics better than we can. Our optimizations might help make our code faster or smaller in one way but their framework makes it balanced in all ways.

Again, you're just providing generalities instead of engaging with the
actual, relevant question: why should runtime tuple indexing be gated
off to a specific type when `std::tuple` is able to do it? What is
your evidence that a type specifically optimized for runtime indexing:

1. Would be faster than `tuple` in actual applications of runtime indexing.
2. That `std::tuple` would be so slow slow to do runtime indexing with
that `std::tuple` needs to be excluded from doing so.

No generalities. No citing Stroustrup or whomever. No theorycrafting.
Provide actual evidence of these specific things for this specific
instance.