Gino Valente

> I think we need a better noun for them: they aren't resources in the sense of `Resource`, and are likely to drift even further away. I think the problem...

To clarify, the proposed API is in addition to the current methods, correct? Otherwise it would be impossible to add anything to `App` (since their `AddToApp` implementation needs to call...

Looks like we're not using the `unit_struct` methods on the serializer/deserializer. We can probably do that pretty easy with a simple field length check (being sure to exclude `skip_serializing` fields).

Clippy's not happy with my choice of naming in `ArgList::next`. Should we rename? If so, to what? So far on [Discord](https://discord.com/channels/691052431525675048/1002362493634629796/1260417783855059045), we've come up with the following alternatives: - `take`...

I just went with `ArgList::take` for now. Let me know if there are any other opinions on this!

> Is there any better alternative to use beyond `type_name()`? (Maybe `TypeId`?) The type name is not guaranteed to be unique, so there's a chance multiple functions could collide. >...

Okay so since function reflection is now behind a feature, I had to add corresponding features to `bevy_app` and `bevy_ecs`. Hopefully, that's okay!

> I think we should probably document somewhere that the blessed way of registering a function with a chosen name into the registry is manually calling `into_function` and relying on...

Update: I brought this up on [Discord](https://discord.com/channels/691052431525675048/1002362493634629796/1267247543344169032) but there's actually a potential problem here: anonymous functions. While we can sorta[^1] prevent closures and their `foo::bar::{{closure}}` type names from being registered,...

I suppose another option could be to mix 2 and 3 such that we return an error when functions are missing a name (i.e. anonymous functions), but provide a separate...