DaniPopes
Please clarify why `ToHex` is deprecated
I wanted to thank you for such a wonderful crate.
It is a bit confusing why the ToHex trait is deprecated.
My use case for the crate includes creating a lot of hexed representations for the byte vectors. And making an allocation each time isn't ideal.
Crates like arrayvec that provide an array-backed strings are ideal for such workloads, however the ToHexExt trait unlike ToHex doesn't allow collecing in there.
So i wonder what would you suggest to do in this case. Is it better to just use the ToHex implementation and ignore the obsolete warning, in which case maybe it should not be obsolete? Or are there any plans of extending the ToHexExt trait to work in cases where alloc is undesirable or completely unavailable?
The closest API I've seen was decode_to_slice/encode_to_slice but it's a bit awkward to use because you need to track the length of written characters. If there was a way to return an array-backed string instead of std::String without manually juggling arrays and indices it would be a great addition to the lib.
I can add a PR that adds a smallvec impl (gated behind the feature) if you feel like it fits the library.
Sorry for such an abrupt issue.
ToHex is deprecated because it forces an inefficient implementation, mainly iterator API which forces one item at a time, and the item is char which adds even more overhead.
It's inherited from the hex crate and this crate acts as a drop-in replacement for it, so it hasn't been removed.
I agree there's an API gap for stack-allocated buffers. I think the best way forward is something like a generic decode_to/encode_to(&[u8], &mut impl fmt::Write) -> Result<()>. We can also have encode_to/decode_to _smallvec (or also arrayvec) to return it directly just like for String.
If you want to implement the second one it should be straight forward. I'll have to think more about the first one.
