Recursive Type Registration

[james7132]

What problem does this solve or what need does it fill?

Currently registering a type only creates a registration for itself. Registering a type will not register the types of its fields. This means every intermediate field type must be manually registered. This would make deserialization difficult to manage for deeply nested structures.

What solution would you like?

Type registration should be recursive. Upon registering a type, it's field types should be registered. This should continue recursively until a value type has been reached, or if a type had already been registered.

This may increase app load times, but provide a much better developer UX when using the TypeRegistry to handle serialization.

What alternative(s) have you considered?

Register every type manually.

[alice-i-cecile]

I'm strongly in favor of this: this will improve ergonomics significantly.

It's also required for automatic registration of component and resource types to work properly.

[james7132]

We could also likely remove the default type registrations in bevy_core too, since they would be transitively registered by any type that needs them.

[MrGVSV]

Also in favor of this. Just as long as the duplication logic is handled in the registry itself and not by the macro (if that was even an option haha). I just know users— including myself— are going to be accidentally re-registering things that got picked up by a field registration.

[james7132]

This is probably doable as a follow-up to #4042 by just inverting the flow of control of GetTypeRegistration to have a type register itself and its fields into a TypeRegistry.

[cart]

I'm open to considering this, especially if we can show that this doesn't meaningfully affect startup times in complicated apps. Only recursing when a type isn't registered yet will avoid truly bad time complexity, but this still forces an extra hashmap lookup of every type id of every field of every registered struct.

[james7132]

Ideally we could/should do this at compile time, but both const Any/TypeId functions both aren't const yet, nor is inventory available for this kind of use.

I'm also not convinced that repeatedly fetching the TypeRegistry resource, getting a write lock, and inserting registrations for each type is going to be any faster than doing a HashMap::contains_key check for every field in a type, which would eventually amortize to a one layer check since most of the constituent fields will already have been registered.