Allow other primitives as keys

[414owen]

This change makes it possible to use other primitives as keys.
There are a lot of function-level constraints, which could be either
aliased, or lifted to the impl clause, but I prefer to have the
minimal set on a per-function basis.

This is a breaking change, because of the introduction of the extra type
parameter.

[jakoschiko]

Relates to #63

[JesperAxelsson]

It seems like the tests don't pass.

[414owen]

Fixed

[414owen]

@JesperAxelsson looks like there were integration test failures.
Hadn't caught them, because you need to cd integration_tests and run them separately.

Should be all ✅ now.

[jakoschiko]

@JesperAxelsson Any ideas how we deal with the two competing PRs? I think the main difference is that this PR provides a trait that can implemented by the user for any integer type, though it requires num-traits in the public API. My PR tries to keep everything as private as possible using a sealed trait, so only a selected number of integer types would work. Do you have any preferences?

[414owen]

@jakoschiko Well, thanks for bringing this up, at present, HighestPrime isn't public, so can't be implemented by users of the crate.

I will change that though, because I need the feature. I want to have keys that are newtype wrappers around u32, ie struct MyKey(u32). That way, you can have type-safe access to the elements of the intmap.

[jakoschiko]

Another alternative:

struct IntMap<K: IntKey, V> {
    // ...
}

trait IntKey: Copy {
    type Int: Int; // Int is the sealed trait from PR #63
    fn from_int(int: Self::Int) -> Self;
    fn to_int(self) -> Self::Int;
}

// That allows the user to use u32 as key without any wrapper
impl IntKey for u32 {
    type Int = Self;
    fn from_int(int: Self::Int) -> Self { int }
    fn to_int(self) -> Self::Int { self }
}

// Your use case
#[derive(Copy)]
struct MyKey(u32);

impl IntKey for MyKey {
    type Int = u32
    fn from_int(int: Self::Int) -> Self { Self(int) }
    fn to_int(self) -> Self::Int { self.0 }
}

That would require that the intmap crate exposes two different traits, Int and IntKey. But it makes your use case possible and implementing IntMap is easier than implementing the trait HighestPrime and the different traits from num-traits. We could even remove num-traits as dependency.

[414owen]

@jakoschiko I was doing something similar in an internal project until recently.
I had a wrapper around IntMap (the one without generic keys) that relied on From<u64>, and To<u64>.

Your version is admittedly way easier to implement for custom types than all of the separate num_traits traits in mine, some of which don't even have derive macros -_-

Would you be open to adding this change to your PR? If I can use it with custom types. then I'm happy to 👍 yours.

[jakoschiko]

I'll create a new PR soon.

[JesperAxelsson]

@JesperAxelsson Any ideas how we deal with the two competing PRs?

The best way is to discuss pros and cons, as you guys did :)

Keeping it backwards compatible is great of course, but having key and value be in the correct order (IntMap<key, value>) is probably worth a breaking change.

[JesperAxelsson]

Closed in favor of #69