1. If the format we are implementing has a direct representation for the type they are requesting then we forward the call todeserialize_any .

    For example, if we can represent all integer types i8 i16 i32 i64 and they request an i8 and we have an i32 we should return the i32 do not try and coerce the type.

  2. If we cannot represent the type try coerce the value we have into the value they expect, and if we cant do that forward to deserialize_any

    For example if we only have f64 as the only number type and they request an i32 we try convert our f64 into an i32 or if we don’t have a number type and numbers are typically represented as strings then try parse the number from a string.

  3. The first two rules imply this, however for the case of being explicit. Avoid returning errors from the deserializer at all costs. Always forward to the visitor. Ofcourse if the serialized content is invalid then that is an acceptable error, but never return an error for mismatched type vs expectations. (ie, they called deserialize_string and we have map just call visit_map instead of throwing an error.