This applies to all uses of failure but i picked this one since it's a nice concise example

Saying something would "fail" imho implies controlled failure where the caller should be logically be able to deal with said failure (by either a return flag or an exception), doing an out of bounds read may not actually fail in this instance, it may cause a catastrophic failure or it may just return garbage data depending a bit on 'luck' where on the heap we are allocated.

Unless we want to implement rigorous parameter validation (quite possibly at a cost of perf) and error handling in the calling code, i'd lean towards using the phrasing "undefined behavior" rather than "failure"

That makes sense. Thanks.

Shouldn't this be std::vector, not std::Vector?

A future nice thing to have would be an arena allocator, which has a deallocator that does nothing because all memory is reclaimed when the arena is freed. Blenlib has such an allocator, and I like to it universally when working on a big complicated algorithm that allocates lots of things but doesn't really want to or need to free most of them until the algorithm as a whole is finished.

intend -> intent

intend -> intent

not save -> not safe

Since you've been changing all "Return ,..." to "Returns ..." in descriptions of member actions, maybe you want to be consistent and change all "Get ..." to "Gets ...".

Thanks for this. I would love versions of this that:

1. assume there's a standard stream output function available for the value so one doesn't have to define a wrapper or make a lambda to use this in that very common case.
2. a version that prints as blank-separated values terminated by a newline, also assuming there is a standard stream output function available.

Also, versions for the other containers, though perhaps wrapping them in an ArrayRef for debug printing isn't too painful.
Of course, I realize that it is already a bit strange to put debugging-help functions in standard data structures so perfectly understand if you provide no more than print_as_lines.

I would phrase "other than in a vector" as "unlike vector"

Might you also consider adding a debug print function that prints all the key->value mappings in a Map?

Your pattern of using Returns instead of Return in comments is not being followed in this file.

criterions -> criteria

other than in a vector -> unlike in a vector, or unlike vector

Consider having a debugging function to print elements of the Set.

Maybe explicitly state the advantages of using Stack instead of Vector (which is easily used as a stack?)

Thanks for this! I use this all the time.

While I can see the argument for using push_back to mirror std::vector, I am with you in preferring append. I always found push_back a strange and non-obvious name. Python and many other languages use append.

Consider a debugging print for elements.

I agree, that would be good to have. There is already LinearAllocator but we have to think about how to make this work with the containers in a nice way. There are quite a few specialized allocators that I'd like to use in different cases, but I'd say that's a topic for another day.

1. If you scroll down just a tiny bit, you'll find that version.
2. I agree, that is helpful as well.

In general I'm totally fine with adding these debug print functions. We/I just need to think about how to make them consistent between the different containers.

Yes. I did have that at some point, but removed it for now. I'll think about how make these debug prints consistent between the containers.

assoziative -> associative

intend -> intent

intend -> intent

I think that deserves its own separate discussion on devtalk. I'm fine with using C++ casts, although I've yet to see a case where these explicit casts improve readability.