Require components that can't be defaulted

[andriyDev]

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

Today, a required component either needs to impl Default or needs to have an explicit constructor function passed in. This is problematic for components which require some initial state. Consider the following setup:

#[derive(Component)]
#[require(EnemyTarget)]
struct Enemy;

#[derive(Component)]
struct EnemyTarget(Entity);

I want to say that an enemy needs to be inserted with a target, but a defaulted target doesn't really make sense and Entity doesn't even impl Default.

What solution would you like?

require should be able to not use a constructor at all and just require that the bundle inserts the component. Perhaps this could be done with a keyword like #[require(EnemyTarget(explicit))] to say that a component must be explicitly inserted and will fail (at compile time) otherwise.

This would severely decrease the remaining need for bundles.

One downside is that you can still break this invariant by explicitly removing one of the components after the fact, but that is already true.

What alternative(s) have you considered?

Wait for archetype invariants. This would unfortunately mean problems would be detected at runtime.

[alice-i-cecile]

I much prefer non-defaulted required components over using archetype invariants to resolve this problem.

[SkiFire13]

and will fail (at compile time) otherwise

As much as this would be nice to have, I don't think it's something possible to do without some kind of const-comparable TypeId.

[andriyDev]

After implementing #16209, I feel dissatisfied with my own solution. Because of how dynamic we are allowed to be (you can register required components at runtime), the only valid solution AFAIK is just panicking at runtime. This basically seems like worse archetype invariants to me.

[alice-i-cecile]

Yeah, the transitive and dynamic nature of required components makes this quite hard to use effectively.

[andriyDev]

@alice-i-cecile, thoughts on just closing this and the PR and just waiting for archetype invariants?

[alice-i-cecile]

I think I'm in favor of closing this, yeah. I don't see any good way to handle the non-trivial / ecosystem implications, and any full, thoroughly designed solutions feels more in line with a complete archetype invariants design (#1481, for those who are out of the loop).