The primary focus of this release is on polish: making Serde easier to learn and more enjoyable to use. That said, this wouldn’t be Serde without some amazing new features to tell you about as well.

In celebration of this milestone, I would like to highlight some of the work that has contributed toward making Serde the powerful, efficient, adaptable, convenient beast that exists today. This is the unfinished history of serialization in Rust.

March 2011 — Patrick Walton adds support for serializing Rust object metadata into a format called EBML (reader and writer).

— Patrick Walton adds support for serializing Rust object metadata into a format called EBML (reader and writer). November 2011 — Elly Jones adds a JSON library called std::json.

— Elly Jones adds a JSON library called std::json. February 2012 — Niko Matsakis creates a utility to generate serialization code for data structures, eliminating the grunt work of writing it by hand. The first serializer and deserializer traits appear. The same traits still exist practically unchanged in rustc_serialize today.

— Niko Matsakis creates a utility to generate serialization code for data structures, eliminating the grunt work of writing it by hand. The first serializer and deserializer traits appear. The same traits still exist practically unchanged in today. May 2014 — Erick Tryzelaar begins Serde, exploratory work to address some severe, foundational limitations in the standard library’s approach to deserialization.

— Erick Tryzelaar begins Serde, exploratory work to address some severe, foundational limitations in the standard library’s approach to deserialization. December 2014 — Alex Crichton begins the deprecation of libserialize. It is clear that the design has a number of drawbacks, and there aren’t resources to address them in time for Rust 1.0. The code is moved out of the rustc codebase into the rustc_serialize crate.

— Alex Crichton begins the deprecation of libserialize. It is clear that the design has a number of drawbacks, and there aren’t resources to address them in time for Rust 1.0. The code is moved out of the rustc codebase into the crate. March 2015 — Erick Tryzelaar releases Serde 0.2.0, proving decisively that the limitations in libserialize can be resolved by a better approach.

— Erick Tryzelaar releases Serde 0.2.0, proving decisively that the limitations in libserialize can be resolved by a better approach. May 2015 — Rust 1.0 is released.

— Rust 1.0 is released. April 2017 — Serde is impressively fast, battle-tested in production use cases, and ready for a solid 1.0 release.

Thank you to more than 100 people who have contributed improvements, opened issues, provided help to others, or expressed their frustrations with Serde in a constructive way. We appreciate your continued support.

Zero-copy deserialization

Serde 1.0 adds the ability to deserialize into types that borrow from the input data. For example, this JSON document can now be deserialized efficiently and safely into the following Rust struct.

{ "fingerprint": "0xF9BA143B95FF6D82", "location": "Menlo Park, CA" }

#[derive(Deserialize)] struct User<'a> { fingerprint: &'a str, location: &'a str, }

The value for each field will be a string slice that refers to the correct substring of the input data. No memory is allocated for the strings and no data is copied. The same thing also works for &[u8] slices. Other types can be borrowed explicitly by using the #[serde(borrow)] attribute.

This uniquely Rust-y feature would be impossible or recklessly unsafe in languages other than Rust. The semantics of Rust guarantee that the input data outlives the period during which the output struct is in scope, meaning it is impossible to have dangling pointer errors as a result of losing the input data while the output struct still refers to it.

Zero-copy deserialization is discussed in more detail on this page of the website.

Remote derive

One recurrent struggle with Serde is needing to use types from somebody else’s crate where they do not provide Serialize and Deserialize impls.

Rust’s “orphan rule” allows writing a trait impl only if either your crate defines the trait or defines one of the types the impl is for. That means if your code uses a type defined outside of your crate without a Serde impl, you resort to newtype wrappers or other obnoxious workarounds for serializing it.

Serde 1.0 now supports deriving impls for structs and enums defined in other people’s crates.

// Serde calls this the definition of the remote type. It is just a copy of the // remote type. The `remote` attribute gives the path to the actual type. #[derive(Serialize, Deserialize)] #[serde(remote = "nifty::Duration")] struct DurationDef { secs: i64, nanos: i32, } // Now the remote type can be used almost like it had its own Serialize and // Deserialize impls all along. The `with` attribute gives the path to the // definition for the remote type. Note that the real type of the field is the // remote type, not the definition type. #[derive(Serialize, Deserialize)] struct Process { command_line: String, #[serde(with = "DurationDef")] wall_time: nifty::Duration, }

Remote derive is covered on this page of the website, which also includes an example of handling a remote struct with private fields.

Documentation

Lots of new content on the Serde website. The following new pages in particular are a valuable read even for experienced Serde users.

The Serde data model — A new way of conceptualizing Serde’s role in the ecosystem and its type system.

— A new way of conceptualizing Serde’s role in the ecosystem and its type system. Understanding deserializer lifetimes — Helpful reference as you work to upgrade your libraries to Serde 1.0.

— Helpful reference as you work to upgrade your libraries to Serde 1.0. Writing a data format — A complete serializer and deserializer implementation annotated with an explanation of all the pieces.

Is Serde done?

As of this release, Serde is stable but not done. We say with confidence that Serde is the best serialization solution that we can design for the Rust language as it exists today and for the broad range of use cases that we target.

The Serde issue tracker has a long list of planned enhancements for you to look forward to and maybe help us implement. For the first time, none of them involve further breaking changes.

Breaking changes