Description
What problem does this solve or what need does it fill?
Currently, (de)serializing via reflection can be done without registering most types. The only types that need to be registered for (de)serialization to work are non-Value types (i.e. not ReflectRef::Value
) and types with specific (de)serialization type data (i.e. ReflectSerialize
, ReflectDeserialize
, or SerializationData
).
This means we can readily serialize this:
#[derive(Reflect)]
struct Foo {
bar: usize
}
But this needs to be registered first:
#[derive(Reflect, Serialize)]
#[reflect(Serialize)]
struct Foo {
#[serde(rename = "baz")]
bar: usize
}
The interesting thing is, if we fail to register the second one, we still get an output:
{
"my_crate::Foo": (
bar: 123,
),
}
It worked.... just not in the way we intended. And what's worse is we don't get any warning or error indicating that we forgot to register our type.
The example above concerns (de)serialization, but this whole issue could extend beyond (de)serialization and affect future reflection APIs (both first and third party).
What solution would you like?
Make it so that type registrations are required for reflected (de)serialization.
This might be slightly annoying (though, could be aided by something like #4154), but it ensures users never forget to register a type that actually needs it.
Additionally, as the API grows, we may find the type registry to be more and more necessary for accomplishing certain things. This would also ensure types are properly setup for any future use cases as well (this goes for third-party crates too!).
What alternative(s) have you considered?
Printing a warning when a type is missing a registration
This won't really work because we have no way of knowing if a type needs to be registered or not. We could check by calling GetTypeRegistration::get_type_registration
for every value serialized, but this is not very realistic.
And since we can't know what really requires the registration, we'd end up printing a warning for everything that isn't registered— even if it doesn't have to be. And this imo indicates to the user that everything still needs to be registered, which defeats the whole purpose of this.
Keep the silent failures
We could, of course, just do nothing and allow these silent failures. With proper documentation, we could help users be more aware of this issue. However, this doesn't really fix the problem, just raise awareness about it.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status