@reem it looks like there are several unanswered issues and pull requests, with the last commit dating back 2 years. Would you mind clarifying the status of this crate, whether it's recommended to use it, whether it compiles on recent rust?

If you don't have time to maintain this, are you looking for other maintainers? You could check out the rust bus.

Thanks in advance.

Compiling typemap v0.2.1
/Users/APoltarjonoks/.cargo/registry/src/github.com-1ecc6299db9ec823/typemap-0.2.1/src/lib.rs:171:1: 171:42 error: the trait core::marker::Sized is not implemented for the type CloneAny [E0277]
/Users/APoltarjonoks/.cargo/registry/src/github.com-1ecc6299db9ec823/typemap-0.2.1/src/lib.rs:171 unsafe impl UnsafeAnyExt for CloneAny { }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/APoltarjonoks/.cargo/registry/src/github.com-1ecc6299db9ec823/typemap-0.2.1/src/lib.rs:171:1: 171:42 note: CloneAny does not have a constant size known at compile-time
/Users/APoltarjonoks/.cargo/registry/src/github.com-1ecc6299db9ec823/typemap-0.2.1/src/lib.rs:171 unsafe impl UnsafeAnyExt for CloneAny { }

Needed unstable APIs:

• std::collections::hash_map::Entry::*
• std::any::TypeId::of and Eq/Hash impls.

cc iron/iron#317

After rust-lang/rust@400c3a0d implemented RFC 509
HashMap::VacantEntry now takes an additional type parameter Sized? Q: ToOwned<K>
The idea being that HashMap#entry() now accepts the key by reference (&'a Q instead of K).
Then VacantEntry calls Q#to_owned() -> K to store it in the map.

I've been trying to fix this; but I'm stumped. In TypeMap: the caller does not generate the TypeId, instead it is generated internally by TypeMap#entry().

Since no reference to this TypeId would live past the call to TypeMap#entry() this invalidates the Entry<'a, K, V> we're trying return.

The best I've been able to do so far is add a helper method that generates the TypeId and returns it to the caller so it lives long enough; then the caller passes it into TypeMap#entry()... but it's a huge loss for ergonomics.

This is necessary to enable users building with -Zminimal-versions.

When I try to install:

$ cargo install typemap
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading typemap v0.3.3
error: specified package has no binaries

Did I get the crates.io package name right? Is there something I'm doing wrong?

#[derive(Default)] assumes all type parameters should be required to be Default in order for the type to be Default. See documentation for Default impl at https://docs.rs/typemap/0.3.3/typemap/struct.TypeMap.html.

If Default is manually implemented, this restriction should be removed.

I can submit a PR for this, but it's not immediately necessary for what I'm doing. Just noticed it.

This makes it possible to have #[deriving(Default)] on structs containing TypeMap.

The test below panics when added to the test suite, I think associated types are required.

I tried patching it up, but I couldn't figure out the syntax to add a static bound for the associated type (can't find any tests for it in rustc either).

#[test] fn test_entry_multi() {
    impl Assoc<u32> for Key {}

    let mut map = TypeMap::new();
    map.insert::<Key, Value>(Value);
    if let Occupied(_) = map.entry::<Key, u32>() {
        panic!("Unsound")
    }
}

Is there any way to have Eq and PartialEq impl for TypeMaps which support Eq and PartialEq for keys and values?

An old version of typemap has dependencies specified with "*" version requirement (phantom = "*", unsafe-any = "*").

Crates with such vague dependency versions became unusable, because * allows picking too-new semver-incompatible dependencies.
It also breaks Cargo's minimal-versions feature, because * requirement allows picking very very old dependencies that aren't compatible with Rust 1.0.

Because this old version of typemap is unusable and may cause problems for Cargo, I suggest yanking it:

cargo yank --vers 0.0.3

MIT requires text license to be present along with source. Please add it & publish new version.

Thanks in advance!