[Joker_vD]

> a similar type, but whose size and capacity are fixed on construction and never change.

There is std::array for that. Also, for a type with fixed capacity but variable (up to that capacity) size, we're getting std::inplace_vector soon™.

[einpoklum]

std::array requires the size to be set at compile-time, while I was talking about arrays whose size is determined at construction-time. Of course std::array is also quite the useful class :-)

[SJC_Hacker]

You can construct the vector with a given size. As long as you don’t push_back, beyond capacity, these should be o dynamic allocations.

If you want to get f cy you can also give it a custam allocator and throw an exception if you do this by mistake

[einpoklum]

> As long as you don’t push_back

But that's the point. You _can_ push_back, or resize, or reserve, etc. etc. My claim is that the more common use case is the one where this _cannot_ happen.

> If you want to get f cy you can also give it a custam allocator

And then nobody will want to use it, because that's not interchangeable with containers vector with the default allocator, and also difficult to understand. I mean, look at PMR allocators, which are not even that custom. They see very little use I'm afraid.

[Joker_vD]

Well, if you want to, I can write you a forwarder-wrapper around a std::vector that would inhibit allocation-inducing operations. Now, getting it into stdlib, that's a different matter entirely...

Also, do I understand correctly that you want both the capacity and the size fixed, i.e., the container's elements have to be pre-constructed and supplied to the constructor via an initializer list?