Implement TrieKey for integer types. about rust_radix_trie HOT 6 CLOSED

Hi.
The hard thing here is to decide about how endianness will be handled. Depending of the architecture, i.e. u64 can be converted to vectors with different byte orders.
I think I could implement this, but the resulting vector endianness should be decided first.

from rust_radix_trie.

Hi!

Thanks for your interest in contributing! We could possibly integrate with this package:

https://docs.rs/endian-type/0.1.2/endian_type/

By default, we could also provide big-endian (?) implementations for the raw types.

from rust_radix_trie.

Found a problem here.
Trait specifications start to conflict because the existing trait is generic. Specialization RFC could solve it in the most beautiful way, but it's not in stable yet.

As of current situation I can see these choices:

• implement additional trait for conversion to trie_key. You can find the u16 implementation demo here(also notice, we don't need additional crates, but only some "almost-safe" conversion from std) https://github.com/Albibek/rust_radix_trie/commit/01327dd8fd0659c40687b13a9a0d022f0666e003#diff-31726c1a987e5186af9311494986d953R58.
  And example usage can be seen in test: https://github.com/Albibek/rust_radix_trie/commit/01327dd8fd0659c40687b13a9a0d022f0666e003#diff-c5fc4beef0f03493c2e9a9c876073f0fR213
  (other changes in commit are caused by auto-formatting with rustfmt, so they are also probably viable)
• wrap standard numeric types in some enum(or a set of types like U8Key, U16Key etc), like NumericKey or something and implement Into<Vec<u8>> for it.
• (this will probably break API compatibility) downgrade the original trait to some more specific types
• probably remove TrieKey at all because currently it's just a kind of syntactic sugar, that lets programmer to avoid typing .into() for the types he/she is using

from rust_radix_trie.

Oh, and one more question: differentiating signed and unsigned types. From the point of view above we don't do the difference, that means i32 and u32 will be converted to same Vec<u8>.
This doesn't seem to me as a big problem, since same tree cannot have multi-typed keys, but I'm probably wrong, so letting you know about that.

from rust_radix_trie.

I think we should get rid of the blanket implementation of TrieKey for T where T: Into<Vec<u8>>, so we can write implementations for specific types like you suggest. I don't think we should use an extra trait like IntoKey as that mucks up the type of the trie itself, and creates the signedness issue you mentioned. Having Trie<u32, String> and Trie<i32, String> is more informative than having Trie<Vec<u8>, String>, which is what you get with IntoKey.

Don't worry about breaking API compatibility, we are pre-1.0, so anything goes 😄. To that end, I've recently been restructuring things for improved performance and usability. My new changes are on the new-stuff branch which I hope to merge soon. You should base your changes off this.

I think we should use wrapper enums, or some other strongly-typed thing, so we can have Trie<LittleEndian<u32>, String> and Trie<BigEndian<u32>, String>. If we use the endian-type package we can use the as_bytes() function, see:

https://docs.rs/endian-type/0.1.2/endian_type/struct.LittleEndian.html

from rust_radix_trie.

Closed by #22, thanks @Albibek 😄

from rust_radix_trie.