Add finalizer attribute hook to validate a deserialized structure

[erickt]

In servo/rust-url#252, @Manishearth is writing a serde deserializer for urls since parsing a string can be expensive. However, to do this safely from untrusted sources, they need to validate that the data is semantically correct. We unfortunately don't have an easy way of doing this without writing a custom deserializer. It'd be pretty simple to do as an attribute, however. Here's my idea:

#[derive(Serialize, Deserialize)]
#[serde(finalizer="check_greater_than_10")]
struct GreaterThan10 {
    n: usize,
}

fn greater_than_10<D>(item: GreaterThan10) -> Result<GreaterThan10, D::Error>
    where D: Deserializer
{
    if item.n > 10 {
        Ok(item)
    } else {
        Err(Error::invalid_value("less than or equal to 10"))
    }
}

[dtolnay]

This seems relevant: https://github.com/Keats/validator. Let's make sure to support this library in a nice way.

[radix]

My hacky workaround is to

1. don't derive Deserialize for my main data type "DataType"
2. copy my main data type to a "FakeDataType" which has the same fields, and make this one derive Deserialize
3. implement Deserialize for DataType by:
   1. invoking deserialize to FakeDataType
   2. validate the result
   3. convert FakeDataType to DataType.

It's a dumb hack but at least it allows me to avoid rewriting all the deser code manually.

[dtolnay]

#626 has another use case.

I am on board with implementing exactly the approach in @erickt's comment.

[oli-obk]

Another use-case from irc by @alteous

I would like to obtain a maximum integer value from a tree of structures. The context is these values are offsets into arrays, and I want to check that they are all valid ahead of time. The integer values are wrapped in Index types.

[beamspease]

I believe I could also use this for an enum which is either "unknown" or some value fitting a specific pattern, but both are strings.

[Mange]

I have the same usecase as in #626. I want to load shapes, and I also want to store some precomputed attributes on them that are derived from the other fields (for example radius_squared = radius * radius).

I don't want to serialize or deserialize these fields, but I want them to be present in the finished structs. The shapes could be deeply nested in another structure that is loaded, so it's very messy to try to go down the structures in a mutable fashion and set it on the structs manually.

[scottmcm]

Perhaps a silly question, but why an attribute instead of a trait? I pictured:

trait SerdeFinalize: Sized {
    fn finalize<E:Error>(self) -> Result<Self, E>;
}

#[derive(Serialize, Deserialize)]
#[serde(Finalize)]
struct GreaterThan10 {
    n: usize,
}

impl SerdeFinalize for GreaterThan10 {
    fn finalize<E:Error>(self) -> Result<Self, E> {
        if self.n > 10 {
            Ok(self)
        } else {
            Err(E::invalid_value(Unexpected::Unsigned(self.n as u64), &"a number above 10"))
        }
    }
}

(And maybe #[serde(Finalize)] would no longer be needed once specialization is stable and everything could get a default no-op finalizer that's overridable if desired.)

[TedDriggs]

I've been working on something related to this for derive_builder. My assumption has been that the two-step process:

1. Gather data from some outside source into an intermediate struct
2. Finalize the domain type (perform semantic validations, generate cached values, RAII, etc.)

should be split across two different types, and that the sidecar type could be generated through a combination of macros, i.e. deriving a Builder which in turn derives Deserialize. In that world, field-level validations would be handled through types, rather than the attributes in the validator project.

I've run into a few hurdles so far:

1. I don't know of a clean way to invoke TryFrom<...> that doesn't require writing manual deserialization code. This makes fallible conversions to domain-specific types (like "Credit Card" or "Email") very tedious to write. I'm hoping that the stabilization of TryFrom will pave the way for a more reusable solution.
2. Surfacing errors of many different types to the outer caller requires boxing or other approaches that complicate error inspection.
3. Getting multiple errors during a single deserialization isn't possible.

[lucab]

Cross-referencing Keats/validator#22.

It looks like one of the main concerns there is how to bubble up structured/detailed errors when validation/finalization fails. If anybody has usecases/opinions, it would be nice to feed them back there.

[TedDriggs]

There seem to be two situations for this:

1. After deserialization, perform an infallible transformation `FnOnce(T) -> T
2. After deserialization, perform a fallible transformation FnOnce(T) -> Result<T, E: serde::de::Error>

From a naming perspective, these seem exactly like map and and_then. It probably shouldn't be valid to declare both on one type/field.

@lucab I've been going back and forth on the errors front. Having that function return a serde Error is really useful for composition with this feature; maybe users can handle that conversion in their own code?