Allow deserializing from disk

[yoshuawuyts]

Feature Request

Summary

Enable the Deserialize trait.

Motivation

This allows files to be read from disk and parsed using this crate.

Guide-level explanation

Explain the proposal as if it was already included in the project and you
were teaching it to another programmer. That generally means:

• Introducing new named concepts.
• Explaining the feature largely in terms of examples.
• If applicable, provide sample error messages, deprecation warnings, or
  migration guidance.

Drawbacks

None

Rationale and alternatives

This makes this crate useful for both serializing and deserializing.

Unresolved Questions

Right now there's some lifetime problems that need to be figured out when implementing this.

[maxdeviant]

I started taking a look at this, and it seems like the pain has to do with using Vecs of references on the Manifest struct.

// This fails to compile.
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct Manifest<'s, 'i, 'r> {
  // ... elided
  #[serde(borrow)]
  icons: Vec<&'i Icon<'i>>,
  #[serde(borrow)]
  related_applications: Vec<&'r Related<'r>>,
}

// This compiles fine.
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct Manifest<'s, 'i, 'r> {
  // ... elided
  #[serde(borrow)]
  icons: Vec<Icon<'i>>,
  #[serde(borrow)]
  related_applications: Vec<Related<'r>>,
}

So far I have yet to find anything in the Serde docs about deserializing references

[maxdeviant]

According to this comment:

Oh working with collections + attributes is currently obnoxious because we don't yet have a way to apply attributes to the content of a collection. This is tracked in #723.

It is possible to make it work but unless you really need it, I would recommend sticking to owned types in collections (just like you would have in any previous version of Serde).

It does list a (rather ugly) workaround that we could try.

Thoughts @yoshuawuyts?

[yoshuawuyts]

@maxdeviant ugh, yeah, it probably needs to be owned then. Shame :(