Replace FromWorld blanket implementation with derive macro

[Shatur]

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

Currently resources can have either FromWorld or Default trait implementation because of blanked FromWorld implementation. This causes inconveniences with other crates integration. For example, confy crate requires configuration structure to have Default trait, so I can't create a convenient FromWorld for it.

What solution would you like?

I would suggest to switch to explicit derive macro.

[cart]

Implicit FromWorld impls for Default impls means that we can use both traits in things like app.init_resource::<T>(). Requiring a derive seems like it would be a pretty massive ergonomics (and conceptual) loss, as it would mean we can no longer rely on Default impls in these cases. Anything that currently uses a default impl would either also need a manual FromWorld impl or would need to replace Default with FromWorld. I'd want to see how this affects real-world use cases (and the official bevy examples) before committing to it.

Right now thinking about FromWorld as "Default but for things that need World access" seems to be working reasonably well. Use Default generally, unless you need world access. Then implement FromWorld instead. If you can implement Default, by definition you don't need FromWorld. What is the specific use case you're trying to enable?

[alice-i-cecile]

As a more scoped workaround:

1. Remove the blanket impl of FromWorld for T: Default.
2. Modify the init_resource methods to only take T: Default.
3. Create a new init_resource_from_world method that takes T: FromWorld.

I would also like to hear a bit more about the use cases before pursuing that though.

[Shatur]

Thanks for the replies!

Right now thinking about FromWorld as "Default but for things that need World access" seems to be working reasonably well. Use Default generally, unless you need world access. Then implement FromWorld instead. If you can implement Default, by definition you don't need FromWorld. What is the specific use case you're trying to enable?

Sometimes I need to have Default trait and a different FromWorld implementation. For example, here I have a struct that used as a resource and read from command line. I have defaults() function that I use for default initialization and FromWorld implementation that checks if the command line argument was provided.
Right now my defaults() function is just a function that doesn't implement Default trait because of the mentioned limitation.
Is this a valid use-case?

[alice-i-cecile]

The workaround doesn't seem too bad: I'm reluctant to degrade the common-case UX for this. Would my solution with split methods work for you?

[Shatur]

Would my solution with split methods work for you?

Yes, it's much better then I suggested. And I like its explicitness: init_resource - uses Default trait, init_resource_from_world - obviously uses FromWorld.

[alice-i-cecile]

Agreed: I think its explicitness is quite good, and from a UX perspective I would say that's probably a wash when weighed against adding yet another set of methods.

I think overall I'd personally be happy enough to see a PR with that change (although in the long-run this feels like yet another "plugins should be structured" problem).

[cart]

Idk if I want to add another dimension to the "resource setup" category of things:

• init_resource
• init_non_send_resource
• init_resource_from_world
• init_non_send_resource_from_world
• insert_resource
• insert_non_send_resource

(with impls on both World and App)

Thats a pretty big set of apis for users to sort through. And it means that if we need to add another variant in the future, this set of apis will "balloon out of control".

[alice-i-cecile]

Yep, same problem as #1978. Unfortunately I don't really see a good way to apply the pattern used there here :/

[Shatur]

Got it, probably there is no good solution. I will move my resource initialization into "plugin" as a workaround then.