Make Component opt-in

[concave-sphere]

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

Currently, Component is auto implemented for any type that is Send + Sync + 'static. This has some benefits:

1. Convenience
2. Allows direct use of pre-existing types as components

But there are also some downsides:

1. There's no way to prevent Bundles from being used with Component APIs, such as in commands.insert(bundle). This results in confusing and hard to track down bugs for newbies, and the number of "danger spots" you have to learn to step around as part of the Bevy learning curve.
2. It's easy to create an unclear architecture where it's not obvious what's supposed to be a component.
3. Using foreign types as components is likely a land mine / attractive nuisance, because another package could come along with the same idea and conflict with your use. It would IMO be better to discourage this pattern so users don't shoot themselves in the foot.

Number one is hopefully obvious. I haven't written a large Bevy program yet, but based on my experience in other domains, numbers 2 and 3 are likely to become a nuisance. Allowing arbitrary types to implicitly get used as a channel for passing data sideways works great for small programs, and rapidly becomes unmanageable as the system size expands. At my workplace we can mitigate the danger with strict code policies, but I don't think that strategy will work with crates.io.

What solution would you like?

Don't auto implement Component. Instead, provide a derive macro:

#[derive(Component)]
struct MyCounter(i32);

The trait impl it expands to is trivial:

impl Component for MyCounter {}

This is almost as convenient as the existing code, while ensuring that types can only be used as Components if they were intended for that purpose. By default, it prevents using a Component as a Bundle (since you'd have to opt in to both types).

There is a question of what to do with generic types. I would suggest this:

#[derive(Component)]
struct MyGenericComponent<T>(T);

// Expands to:
impl<T> Component for MyGenericComponent<T>
    where T: Send+Sync+'static {
}

I didn't require <T> to be a component in this case: by wrapping T in MyGenericComponent, we've declared our intent to make it a Component. The orphan rule ensures that only the owner of MyGenericComponent<T> can implement Component on it (either as a blanket impl or as an impl for one instance). It would be possible to be stricter, but I think this is a good compromise between convenience and safety.

What alternative(s) have you considered?

I don't see any way to fix the problems listed above as long as Component is auto implemented, but there may be some other trickery that my Rust type fu is too weak to see.

[alice-i-cecile]

This has been brought up in other contexts before, and your arguments are valid. Avoiding the bundle-component confusion would be particularly nice, and negative trait bounds will be an eternity to hit stable.

The main concerns are:

1. The addition of required boilerplate.
2. Using foreign types as components. You can bypass this with a wrapper type.

Perhaps we can soften the boilerplate blow by eliminating the need to register components to specify their storage type as part of this change; which would allow that information to be specified much more locally.

This change may also enable interesting features like "immutable components" down the line, or soften the cost of requiring Clone (#1515) on components.

I'm personally in favor of this, but it's a change that should be made deliberately. This is a prime candidate for an RFC once #1662 has landed :)

[DJMcNab]

I am also in favour of this. My 'planned' solution would:

• Change Component to look like:

trait Component {
     fn maybe_register_as_reflect(...)->Option<...>;
     fn storage_type() ->Option<StorageType> {None}
}

• This makes reflecting a key part of components directly, which means that most component types will implement reflect.
  • This is good for scene saving (not gnarly hot reloading 👀) and for the editor
• Add derive(Component), with attributes to support all cases ({no reflect, automatic reflect [default], manual reflect}\times Option<StorageType> [default to 'None', which will probably be dense, although we might not guarantee that (e.g. moving to sparse automatically based on access patterns)])
• Remove the default impls of Component
• Implement component for a specific set of default types (not tuples of T0, T1,T2: Component, not &'static T: Component, yes [T: Component; N], yes Box<T: Component> , yes Arc<T: Component>)

This would fix #392, (and probably #1794)

[BoxyUwU]

Doing this would allow for kinded entities #1634 to be as the target type of a relation #1627 as we could have an associated type for the target type of the relation kind.

[alice-i-cecile]

We should consider whether we want to do this for Resources as well. This would enable a proper solution to #1891 for instance, which would be very useful for the editor.

[DJMcNab]

In my mind, the default state is applying it for resources. We'd have to have some very good reasons not to.

[alice-i-cecile]

In my designs, I'm finding I would also like opt-in an opt-in Event trait. This seems like a natural extension of this idea in a similar way.