[Feature Request] ByteOrder::read<T>

[kitlith]

Add

fn read<T>(buf: &[u8]) -> T;

to the ByteOrder trait.

In my case, this would be useful so that I can create a wrapper type that specifies the byte order of an integer without having to create an implementation for every integer type. i.e.

struct EndianWrapper<T, Endian>(T, PhantomData<Endian>);

// later
Endian::read<T>(src);

Downsides/Arguments against:

• This doesn't cover u48/i48, as there is no native type for it.
• This requires a second set of one-for-each-type impls, though read could be implemented in terms of read_foo or visa versa.
• This could (should?) be done in a seperate library with a seperate API.

This API may have been considered and discarded previously, but I couldn't tell and wanted to double check to make sure.

[kitlith]

... immediately after opening this issue I noticed read_uint, which if you make use of TryFrom/TryInto already lets you implement something similar like this: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0fe4511284d8010049089665d17aa411

(it's not perfect, but it's better than I anticipated beforehand)

[BurntSushi]

It looks like there's some overlap here between this and #95 and #27.

fn read<T>(buf: &[u8]) -> T;

Are you proposing this signature as something that is actually implementable? Because I don't think it is. You need some kind of additional information about T, which implies more traits and thus more API surface area and more machinery.

Generally, I think you should just write out the case analysis for stuff like this. Of course, if you can use read_uint, then that would be better still. If you need static dispatch, then yeah, I think you should just build up your own machinery for it internally.

[kitlith]

No, I don't think it's directly implementable, I just wanted to propose roughly what it'd look like to the user, i.e. read(src) -> u32 and such.

I think this overlaps more with #27 than #95, as the latter seems to be more about run-time dispatch than static dispatch. Regardless, I think your stance after reading the other issue threads is that you think this would complicate the API presented by byteorder, and should be implemented elsewhere.