A slab is very similar to a vector, with one quintessential difference: you don't get to choose your index. Instead, when inserting data [15], you receive the data's index as a kind of key that you can use to access it again. It is your responsibility to store this key somewhere; otherwise, the only way to retrieve your data is by iterating over your slab. The flipside is that you don't have to provide any key either. In contrast to a HashMap, you don't need any hashable objects at all.

A situation in which this is useful is in a connection pool: if you have multiple clients who want to access individual resources, you can store said resources in a slab and provide the clients with their key as a kind of token.

This example suits the second use case of a slab really well. Suppose you only accept a certain amount of connections at a given time. When accepting a connection, you don't care about the exact index, or the way it is stored. Instead, you care only that it is stored in a retrievable way, and that it doesn't exceed your limit. This fits the bill of the slab quite nicely, which is why most of the time you won't be creating a slab with Slab::new(), but with with_capacity, set to a constant upper limit [9].

The slab, however, does not impose this limit by itself, as it behaves exactly like the vector in the way it handles capacity: as soon as the length exceeds the capacity, the slab reallocates all objects to a bigger block of memory and ups the capacity. This is why, when dealing with upper bonds, you should insert your data with some kind of variation of line [38]:

    if slab.len() != slab.capacity() {
        slab.insert("the slab is not at capacity yet");
    }

Other valid approaches would be to wrap an insertion in a function that returns a Result, or an Option.