> There's a single "I guess I would use this" container type, std::vector.

About that one... I would claim that in a majority of cases where an std::vector is used, what the author really wanted was a similar type, but whose size and capacity are fixed on construction and never change. The standard C++ library does not offer such a type - so people use vector because it's handy.

Agree with your takes on most of the containers. I also dislike how optionals are never used with containers as they were standardized later (and even then, problematically w.r.t. references). Thus, for example, if I lookup an object in a map of T's, the result should IMNSHO be an optional reference to a T.

▲

Joker_vD 2 hours ago | parent | next [-]

> 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 an hour ago \| parent [-]
		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 :-)

▲

afdbcreid 4 hours ago | parent | prev [-]

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 3 hours ago \| parent [-]
		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.