Add optional Little Endian support

[TyOverby]

Once RFC 213 is implemented, we should allow optional endiannes to be added to the bincode encoders and decoders.

bincode::encode(something);
bincode::encode::<LittleEndian>(something);

[emberian]

Why is it big endian by default anyway?

[TyOverby]

@cmr: something about network byte order. Was probably a mistake. In the next breaking change I'll likely fix it.

[aldanor]

Looking forward to this as well. It looks like RFC 213 is a good while from being stabilised due to uncertainty re: integer fallback, so maybe providing an explicit endianness parameter (or type parameter), or even encode_be(), encode_le() would be great.

[TyOverby]

@aldanor

What would you think about having the default methods use big-endian, but have an module with endian-choice methods?

once 213 lands, it would be easy to deprecate that module, but in the meantime, it wouldn't hurt new users that don't care about endianness.

Or maybe choosing endianness isn't that big of a deal and we should just make everyone do it until default method parameters land?

[mikedilger]

I'd be using this too. I'd be happy with a temporary separate module.

[aldanor]

There's a few equally valid choices here; I personally think it's also important to be able to serialise with native endianness (use case: serialising a sequence of structs to disk and them reading them back via python/numpy or other process on the same box/cpu which would use the native byte order by default). byteorder already provides NativeEndian so that's easy.

Off top of my head, I would probably expect a binary serialisation library to use native byte order unless explicit endianness is specified by the user. This has most chances to work for careless cross-process communication. Second best would be little endian since that's what all Intel CPUs are... most unexpected would probably be big endian (for general-purpose encoding/decoding, that is).

I wouldn't mind having to provide endianness explicitly though, until 213 lands (if it lands); then it's a separate choice of selecting a sensible default :)

[TyOverby]

Honestly I'm leaning towards explicit endianness right now. It doesn't seem like a huge hit to usability and makes it pretty obvious what's going on.

[TyOverby]

I'm just hoping that I don't get hit with bugs from people using different endianness for encoding and decoding...

[burdges]

In C, there is a slight advantage to using "network byte order" aka big endian because you must write every endian conversion manually, so if you leave one out then it breaks on your little endian development machine, but this does not apply to Rust. In Rust, one should probably specify the endianness in a type parameter, not sure all type parameters accept defaults though.

[aldanor]

cf. #103