feature request: Better tolerance for missing fields in derived hydrate for forward-compatibility

[aran]

If I have a struct TOld and add a field to my code to make TNew, I may want to hydrate a TOld into a TNew.

As a concrete example, if I add a new Option<X> field, (perhaps configurably) it should treat missing field as a None.
If I add a field that has implements Default I could also see it treating a missing field as that ::default().

Currently the Hydrate implementation for Option throws an Unexpected when a field is missing.

Quick notes:

• There's lots of decisions needed in how the API could look for this
• I think in general this kind of forward-compatibility should be doable if semantically TOld is a subtype of TNew (Liskov substitutable)
• Thinking about forward-compatibility obviously raises the idea of push-safety / backward compatibility, which would suggest explicitly doing the opposite of Autosurgeon reconcile not clearing all old data #46 so old code could still read new documents. I believe changes are backward compatible if TNew is a subtype of TOld.

[alexjg]

Does the missing= attribute address the migration problem?

[aran]

...I just came back here to mea culpa after seeing it.

I'm going to say "kind of", because it's a subjective API decision, but I'll note that my naive expectation was that Option<X> would behave that way out of the box. Not sure of the right call.

Looks like the following little utilities work fine with missing= (?), which would ease the burden a little.

fn none<T>() -> Option<T> {
    None
}

fn default<T: Default>() -> T {
    T::default()
}