Add byte conversions

[hecatia-elegua]

Closes #33.
this is for testing big endian:

cargo miri run --target mips64-unknown-linux-gnuabi64 --example readme
cargo miri run --target mips64-unknown-linux-gnuabi64 --example nested_tuples_and_arrays

&self or self?
can this rotate_left-then-slice-try_into setup be easier?

also this will probably not stay in bitsize_internal, I still don't believe everyone needs this...
also useful as a trait, I mean it's basically adapted from here / here.

• use a trait

[pickx]

this seems to work from the very basic tests I did

I asked around and if the bounds check of try_into() don't get removed (which they should if the compiler can prove it), we can unwrap_unchecked() to force it out.

in the target_endian = "big" case, can we just return full[size_difference..].try_into().unwrap() and avoid the rotate?

&self or self?

if we go by the API guidelines it should take &self (for non-Copy types, into_ is used for consuming conversions, to_ for non-consuming).

why does this not work for non-repr enums?

this could be a good place to use enum.value() so that something like Subclass::from(42).to_ne_bytes() would return the expected value.

[hecatia-elegua]

can we just return full[size_difference..]

👍

&self (for non-Copy types

right, it was about Copy

why does this not work for non-repr enums?

rust doesn't know that the enum is u32, so it will not allow transmuting unless you define the repr

Subclass::from(42).to_ne_bytes() would return the expected value.

it returns [3, 0, 0, 0] on lil, [0, 0, 0, 3] on big endian right now, which is correct, right?

[pickx]

is this just transmute_copy(self)? because it's already in little endian?

[hecatia-elegua]

that's true, that's also how the impl started.
though it's a bit more explicit like this, but I might change it back when doing the other methods

[pickx]

rust doesn't know that the enum is u32, so it will not allow transmuting unless you define the repr

ah, I see.

Subclass::from(42).to_ne_bytes() would return the expected value.

it returns [3, 0, 0, 0] on lil, [0, 0, 0, 3] on big endian right now, which is correct, right?

I would expect [42, 0, 0, 0] / [0, 0, 0, 42] here

[hecatia-elegua]

I would expect [42, 0, 0, 0] / [0, 0, 0, 42] here

that's Subclass2 :)
oh wait you mean Subclass2 doesn't work? you're right, meaning we would need to handle enums differently

[pickx]

I would expect [42, 0, 0, 0] / [0, 0, 0, 42] here

that's Subclass2 :) oh wait you mean Subclass2 doesn't work? you're right, meaning we would need to handle enums differently

oops, yeah. I meant Subclass2 and it does behave like Subclass (discarding the value of the fallback), unexpectedly

[hecatia-elegua]

@pickx any non c-like enum or struct containing a non c-like enum can't be transmuted since it contains discriminant and value...
my only idea rn is to add your .value() idea to all items and transmute what it gives back, which would make readonly fields unsafe when we support those.. or you just can't convert stuff with readonly fields, uuhhh