Add Serde support

[dtolnay]

As suggested by Shepmaster in http://stackoverflow.com/a/38804932/6086311.

Providing a Serde Serializer and Deserializer would give your crate an API that is consistent with tons of existing Rust data formats (JSON, Bincode, CBOR, YAML, MessagePack, Pickle, Hjson, XML, many others).

Also it would allow me to serialize my own types to BERT:

#[derive(Serialize, Deserialize)]
struct Point {
    x: f64,
    y: f64,
}

let pt = Point { x: 2.3, y: 4.5 };
let result = bert::serialize(&pt);

which is much nicer than having to use BertTuple all over my own crate or having to convert my structs to BertTuple before serializing them.

[Relrin]

Hi, dtolnay!

Thank you for opening the issue here. I've overlooked the serde-rs library, but found a lot different issues which disturb me:

• A lot of "magic" around macros and default tuple type (which implemented with macros in the Rust language also)
• Need to override all possible methods, that is not convenient for me

But from the other side, this let to use crate easily, if it will be a part of the serde-rs crate, as plugin. I'm agree with this proposal. However, I'm really don't want to support a behaviour, which is not described at the bert-rpc document. For example:

• What to do with usize type? It should be the i32 or u8 type?
• And with the i64 type? Trim to the i32 type?
• The same situation with... a struct. In the Erlang language I can describe structure as I wish. It can be {point, {x, 1}, {y, 2}} or {point, 1, 2}. But in the Rust language, how we can let the same feature to a specific user with #[derive(Serialize, Deserialize)] macro? How he can control this behaviour?

And so on...

[dtolnay]

Thanks for the feedback.

• The "magic" is no more or less than what Rust uses for #[derive] for any of the built-in traits. See The Book. Idiomatic Rust already uses #[derive] for the Clone, Copy, Debug, Default, Eq, Hash, Ord, PartialEq, and PartialOrd standard library traits. Serde extends this to the Serialize and Deserialize traits.
• Regarding overriding all possible methods, interestingly most other people had the opposite feedback. Given the huge variety of formats that Serde supports (binary formats and text formats, self-describing formats and non-self-describing formats) it is impossible to come up with reasonable default implementations that work for a "typical" format because there is no such thing. Any default behavior we provide would lead to bugs in a format that mistakenly does not override the default behavior. Every format thinks their own behavior should be the default but of course that is impossible.
• Your BERT serializer's job would be to define conventions around how these Rust types map to BERT types. You do not need to support all types if it is not possible within the scope of the bert-rpc spec. For example it is fine to always error in the serialize_usize method, it just means that people cannot serialize things containing usize to BERT. You could also serialize usize as a tuple of eight bytes (u8 u8 u8 u8 u8 u8 u8 u8) or any other convention you come up with. Do whatever you think is going to be most convenient for most users.
• Serde distinguishes between tuple structs and ordinary structs so I would suggest serializing struct Point { x: i32, y: i32 } as {point, {x, 1}, {y, 2}} and serializing struct Point(i32, i32) as {point, 1, 2}. This gives users of the API control over the behavior.

Again, the whole point is so that I can use BERT without doing either of these unpleasant things:

• Passing around BERT-specific types in the rest of my crate just because at one point they were serialized as BERT. I don't want code that is far separated from the serialization layer to be using BertTuple and similar types.
• Writing my own error-prone conversion logic to convert my structs back and forth to BERT types. This is much more tedious than simply using #[derive(Serialize, Deserialize)] and is very easy to do incorrectly.

Serde support would allow me to use BERT with my own data structures used in the rest of my program.

[dtolnay]

Looks good so far! Once you publish the first release containing Serde support, I will add a link to this repo at https://serde.rs/.

[Relrin]

@dtolnay I'm going to make a release for v0.1 or bert-rs crate. At the moment it will be support only serialize from Rust types to the Erlang format. Could you help me to write remaining deserializers (especially where I have troubles)? For deserializers all what has left: list / tuples, BertBigInteger and special kind of tuples which represented as {bert, ...}