Convert between int and bytes #189

[kaidokert]

Picking up #103 from @flier to rebase and factor in feedback. Making a quick draft first

[kaidokert]

Hm, i get the rest of the builds green, but no idea how to make doctests not to break with 1.8, because attributes on non-item statements and expressions are experimental. (see issue #15701)

[kaidokert]

Ok i got all doctests to pass here ( sample run ) although dealing with 1.8 is very clunky.

[kaidokert]

Ping - any chance of unblocking the workflows ?

[ctrlcctrlv]

Is this crate simply abandoned?

[ctrlcctrlv]

(It's not: see #189 (comment))

[ShaneMurphy2]

Tried out the PR directly from the branch, ergonomics is a bit weird where calling to_be_bytes then passing the return value to a function expecting a byte slice complains that it found the associated type instead of &[u8]. You essentially have to call .as_ref() to use the value where a slice is expected.

[kaidokert]

Ping for @hauleth, perhaps you'd be able to unblock the CI checks ?

[kaidokert]

Rebased on master again - checks are green.

[kaidokert]

Is there any interest still in landing this ? I can rebase/reintegrate if yes. Would be really nice to get at least checks ran

[cuviper]

Yeah, sorry, go ahead and rebase and I'll review it.

Note, the master branch now requires Rust 1.31, so I think to/from_bits will ease the fallback float implementation.

[kaidokert]

Rebased, had to end up squashing.

So to/from_le_bytes for integer types unfortunately only exists since 1.32 and floats from 1.40, so that doesn't actually clean up the implementation.

to/from_bits don't seem to directly help as it can convert u32->f32 but not a [u8;1] to f32

[cuviper]

You already have a decent fallback for integers, so what I meant was that the float fallback can be something like self.to_bits().to_le_bytes() and Self::from_bits(<$I as ToFromBytes>::from_le_bytes(&bytes)). That doesn't need to care whether the integer part is using the native version or fallback.

(And if you peek into the standard library, that's basically how the native float methods are implemented!)

[kaidokert]

Thanks - yes that worked better. Please have another look.

[kaidokert]

Periodic ping for this PR. Would be really nice if the workflows could be allowed run.

[cuviper]

Hmm, I don't see the workflow button, but let me try pushing a rebase...

[cuviper]

The implementation looks good. I'm now thinking more about the API design, and maybe we should split it up, like:

• trait ToBytes for to_*_bytes methods
• trait FromBytes for from_*_bytes methods
• trait NumBytes as an empty meta-trait covering the constraints you have on type Bytes, and a blanket impl.

The main reason to split To/From is because we could add To implementations for NonZeroU32 et al, but those can't safely implement From unless we make them panic on 0.

What do you think?

[kaidokert]

Thanks for taking a look and sorry for long response. Yes, splitting it up looks like a good idea, pushed the change with last commit here. Unsure if NumBytes should be public/exported for anything ?

Please have another look ( workflows pass ).

[blakehawkins]

I would also find this useful!

[cuviper]

After trying this with num-bigint, I figured FromBytes::Bytes should allow unsized so that can be [u8] in that case. I also added default impls for the to/from_ne_bytes based on target_endian, as that seems to be convenient. Let me know what you think!

(I also changed a few other things in the implementation, not affecting API.)

[kaidokert]

Those all look like great additions and clean-ups to me, API is much better. Thanks for those.

Is there anything else that needs to be done before merging ?

[rdaum]

I've been using this feature ( through manual commit hash in Cargo.toml) as part of a datastructure I've written (e.g. https://github.com/rdaum/rart-rs/blob/main/rart/src/keys/array_key.rs#L25), and wondering what the status on it is? If there's no reasonable prospect of it getting merged, I will have to look for another solution, but was hoping to see this PR land.

If there's any testing, etc. I can help with, let me know.

[cuviper]

bors r+

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• Format
• No Std
• Test (1.31.0)
• Test (1.35.0)
• Test (1.37.0)
• Test (1.38.0)
• Test (1.44.0)
• Test (1.46.0)
• Test (1.53.0)
• Test (beta)
• Test (i586)
• Test (nightly)
• Test (stable)

[cuviper]

Sorry again for the very long delays, but this is now published in 0.2.16!

[kaidokert]

Thank you !!! Great to see persistence paid off 👍