Non-overwriting insert commands

[alice-i-cecile]

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

When doing more complex work with bundles, users often end up combining two related bundles, overwriting all values set when they add the second bundle.

What solution would you like?

Add try_insert_bundle(bundle: impl Bundle), try_insert::<C: Component>(component: Component) commands.

These act like their non-try versions, but do not overwrite existing components of the same type.

As part of the same PR, include try_insert_resource and try_insert_local_resource for consistency (and related uses).

What alternative(s) have you considered?

Better bundle merging tools.

Make this the default behaviour, and instead change the current behavior to something like force_insert.

Additional context

Handling the results of these commands relates to #2004, and should probably be left as part of that.

[alice-i-cecile]

I'm not convinced on the names; bikeshed away.

[minecrawler]

I'm not sure this is a good solution to the initial problem. Bundles using the same identifiers, in the worst case for different things, sounds like a nightmare (reminds me of Skyrim mods). Bevy should set standards imho. Things like best-practices bundle authors can follow to create bundles which do not collide with other bundles, or create bundles which can enhance other bundles in a clear way.

[alice-i-cecile]

Bundles using the same identifiers, in the worst case for different things

Identifiers will always work on the type level, so I don't think we'll get collisions in the way you're worried about. Rust's name-spacing strategies will work for us already.

Reuse of components between plugins is both inevitable and desirable IMO. Transform is the obvious example: you can easily imagine multiple compatible bundles that want a transform, and I'd prefer to have the ability to toggle the overwriting behavior than needing to manually check or recomposite all of the provided bundles.

[ahmedcharles]

When I originally read this, I thought the issue was that components were getting silently overwritten and therefore, the developer wasn't even aware of the issue. The linked PR and the proposed feature of having a bundle builder api doesn't actually address the question of whether the developer even notices that two bundles insert a conflicting component.

I.e. there are two issues:

1. Are two conflicting components being inserted for the same entity?
2. Knowing that two bundles insert conflicting components for the same entity, how does the developer ergonomically end up inserting the right one?

Is there an existing solution for 1? And if not, how are non-experts supposed to know that the problem even exists?

[ahmedcharles]

Note, std::collections::HashMap uses the word insert to name an operation which doesn't change existing data and replace to name an operation which does. Granted, in those cases, the values are returned and perhaps that isn't as appropriate here (for performance reasons) but being consistent with the terminology might be helpful before stability is a bigger consideration.

[alice-i-cecile]

Note, std::collections::HashMap uses the word insert to name an operation which doesn't change existing data and replace to name an operation which does

I like this nomenclature a lot. I personally would like to move towards this.

Overall I think this issue should probably be tackled after #2241.

[CMorrison82z]

Is this still on the table?

[alice-i-cecile]

Yep: should be straightforward enough, just hasn't been a priority. Feel free to adopt the linked PR or start fresh and ping me for review.