See this test case provided by @chrysn

#[test]
fn use_across_slots() {
    let mut a: Slots<u8, U4> = Slots::new();
    let mut b: Slots<u8, U4> = Slots::new();

    let k = a.store(5).expect("There should be room");

    b.take(k);
}

Use this issue to collect issues, ideas towards a 1.0 release.

Current open topics:

• Naming. The inclusion of SlotMap will make the Slots name even less descriptive and useful.

To Do:

• Fixed size SlotMap implementation based on this talk
• Optimize the next_free member (#13)
• Iterator support (Relaxed may have mutable)
• Less cluttered API (#12)
• Option for a more relaxed access mode (#10 or #11 #17)
• Documentation improvements

As this data structure verifies, on access, whether the indicated element is actually allocated (and because keys can outlive their elements anyway -- after all, they are keys and not cursors), it would be convenient to allow a key to be deserialized. Making new public would achieve that, as would a from_index constructor that (unlike new) pre-verifies that the index is within the size range (which might be better than new as it'd allow migration to internal N-dependent size types or even value-limited types as those features become available in Rust).

The particular use case I have in mind for this is the collection pattern of webservers -- it receives a POST, picks a new resource name based on the slots index, and makes that resource accessible until it gets DELETEd. When the client comes back to access or deletes the resource, it passes the key in as a path component.