Add debug checks for misusage of Stash indices about stash-rs

[Stebalien]

The good thing is that you can use Mio's trait Index to make your tickets generic over types that implement it.

Actually, it appears that slab (the crate that used to define Index) now just uses Into + From`. I turned that down in #3 because I didn't feel that it was worth it but now that two people have asked for it, I'll reopen it.

However, I'd still need an extra "DebugIndex" trait for debug checks:

struct Metadata {
    slot_version: u64,
    stash_id: u64,
}

// The `From` and `Into` implementations should probably panic.
trait DebugIndex: From<usize> + Into<usize> {
    fn from(metadata: Metadata, index: usize) -> Self;
    fn into(self) -> (Metadata, usize);
}

The best way to make this work would be specialization. If one wanted debug assertions, one would implement:

#[cfg(debug_assertions)]
impl DebugIndex for MyIndexType ...

If you can figure out a maintainable way to do this that has only opt-in runtime costs and ensures, I'd be happy to accept a patch. However, I don't really have time right now to get something like this working myself.

But maybe I haven't understood what you exactly meant by "I designed it to work with MIO".

It has to be possible to pick an index that's freely convertible to/from a usize. Indices compatible with MIO would be unable to implement DebugIndex`.

[Stebalien]

check if an index passed to methods such as get, get_mut and take was generated before this instance of Stash removed it or was cleared: accesses an "old" entry that is no longer present or has been updated meanwhile.

That's what UniqueStash is for (although you can't disable the check). Do you think I should allow disabling the check at runtime?

check if an index passed to methods such as get, get_mut and take was generated by this instance of Stash.

I could do this in UniqueStash (debug only). However, I generally expect users to implement this themselves if needed (e.g., OwnedTag { owner: u64, tag: Tag } (at runtime) or TagForServiceX(Tag) (at compile time)).

---

Unfortunately, I can't do either for Stash because:

1. It usize tickets because lots of other libraries use them as tokens.

2. I can't even try to encode this information in the usize because I guarantee that if you never have more than N items in a stash at any given point in time, the highest "tag" will be N-1. See #3.

[Stebalien]

Also, sorry about the late reply. GitHub doesn't do reliable notification email delivery 😿.

[Robbepop]

@Stebalien
I didn't know that UniqueStash was exactly for that usage purpose.
But doesn't UniqueStash behave quite differently compared to Stash and wouldn't Stash also very much profit from a debug-build based checking of those constraints?

You are completely right that this feature would require an overhaul of the usize approach for the tickets into a Stash but I do think that the profit would be huge for debugging crates using your Stash while it would introduce absolutely no runtime on release build which is what you want normally. Of course, opinions are different so maybe you could offer different versions of feature flags for different kinds of usages.

In my string-interner crate I also used a generic approach for the tickets and also offered a DefaultStringInterner that has its ticket type set to usize which is a nice design in my opinion.
With this feature implemented, the usize for example would be wrapped by another entity that handles all the checks for debug builds but would be a plain usize for release builds.

[Stebalien]

The problem isn't the overhaul, it's that using usize tickets is a feature. Specifically, I designed it to work with MIO (see http://rustdoc.s3-website-us-east-1.amazonaws.com/mio/master/mio/struct.Token.html).

But doesn't UniqueStash behave quite differently compared to Stash and wouldn't Stash also very much profit from a debug-build based checking of those constraints?

The only difference is that each "slot" is versioned (your second check).

[Robbepop]

The good thing is that you can use Mio's trait Index to make your tickets generic over types that implement it. So you still support usize directly. For example in my current application where I use your Stash I always have to convert between my internal index type and usize which is quite ugly compared to directly using my type in your Stash internally due to it being generic. With genericity it would be easily possible to implement a wrapper with

struct TaggedIndex<T> where T: ::mio::Index {
    tag: Tag,
    timestamp: Timestamp,
    ticket: T
}

impl<T> ::mio::Index for TaggedIndex<T> where T: ::mio::Index { ... }

But maybe I haven't understood what you exactly meant by "I designed it to work with MIO".