[afdbcreid]

What operations could such frozen vector offer that std::vector does not? If there are none, it doesn't need a separate data structure.

[einpoklum]

Oh, on the contrary, the separate structure is needed and useful because it offers _less_, not more:

* APIs/function signatures explain more clearly what are the intended uses of the structure that's passed.

* More potential for compiler optimization

* Some potential for having these on the stack (if the compiler deduces the size already at compile-time)

* More convenient for static analysis

* No plethora of confusing constructors (including the infernal two-element ctors which can be misinterpreted super-easily)

etc.

[nemetroid]

How are any of these achieved by a vector-like type with capacity frozen at construction time?

[quuxplusone]

The reason I'd want "frozen-size vector" is to replace pairs of data members of the form `T* foos; size_t foos_len;` without paying another 8 bytes to store a useless capacity that's never going to change.

But I don't think that makes such a container worth adding to the STL. So far, it hasn't even been worth writing in our own code. But that's the reason I've thought about writing it.

[uecker]

This is how I designed my vector in C. Note it is still not frozen as you can use realloc just fine (even with good performance) and/or external tracking of the capacity in tight loops.

https://uecker.codeberg.page/2025-07-20.html

I probably will still add a version with capacity, because people may insist on it, but personally I like the one without much more so far.