Remove rustc serialize support

[TyOverby]

No description provided.

[dtolnay]

Let's make this a private module and pub use serde::*. We no longer need the namespacing.

[aldanor]

Just wanted to say the same thing, +1

[TyOverby]

👍

[dtolnay]

My thoughts on the public API after browsing https://docs.rs/bincode/1.0.0-alpha1/bincode/:

• I would prefer to merge SerializeError and DeserializeError into bincode::Error and similarly SerializeResult and DeserializeResult into bincode::Result<T>. Nobody cares about the difference between these.
• from_slice and from_reader would be more idiomatic than deserialize and deserialize_from, and to_vec and to_writer rather than serialize and serialize_into.
• Pay attention to ?Sized - the io::Read and io::Write type parameters can be ?Sized, as can the &T where T: Serialize.

[TyOverby]

I would prefer to merge SerializeError and DeserializeError into bincode::Error and similarly SerializeResult and DeserializeResult into bincode::Result. Nobody cares about the difference between these.

Considering how close these enums are, I think this is totally reasonable.

from_slice and from_reader would be more idiomatic than deserialize and deserialize_from, and to_vec and to_writer rather than serialize and serialize_into.

I guess if people are prefixing (e.g. bincode::from_slice) then this has readability wins, but I think that seeing a call to to_vec in the middle of a huge block of code (without knowing what is being imported) could be pretty confusing. Meanwhile, serialize is pretty descriptive.

Pay attention to ?Sized - the io::Read and io::Write type parameters can be ?Sized, as can the &T where T: Serialize.

Could you go more into detail here? I'm not really sure what it is that you're warning about.

[ZoeyR]

In regards to what @dtolnay is talking about. functions like bincode::serde::serialize_into put unnecessary restrictions on their type parameters. Both the W and T should be ?Sized.

[dtolnay]

Could you go more into detail here? I'm not really sure what it is that you're warning about.

Sure! Accepting a ?Sized type parameter for io::Read and io::Write means that it will work with &mut io::Read and &mut io::Write trait objects which are dynamically sized.

use std::fs::File;
use std::io::Read;

fn main() {
    let mut data = File::open("important.bin").unwrap();
    let trait_object: &mut Read = &mut data;
    deserialize_from(trait_object); // requires ?Sized
}

fn deserialize_from<R>(_: &mut R) where R: Read {}

And accepting a ?Sized type parameter for &T means that it can work with dynamically sized implementations of Serialize, which includes str and [T] among others.

fn main() {
    serialize("&str"); // requires ?Sized
}

trait Serialize {}
impl Serialize for str {}

fn serialize<T>(_: &T) where T: Serialize {}

[dtolnay]

I filed #99 and #100 to follow up on the remaining issues in case you don't want to include them in this PR.