Allow for Resource - Component relationships

[Freyja-moth]

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

There may be times where we want a Resource to store an entity where it would not make sense to do so for components.

// It wouldn't make sense for this to be a component as there can only be one.
#[derive(Resource)]
pub struct CurrentPlayer(Entity);

pub struct Player;

Currently there is no way to ensure that the entity is valid such as in the case of Component relationships.

What solution would you like?

Allow resources to be specified in relationships

#[derive(Resource)]
#[relationship_target(relationship = Player)]
pub struct CurrentPlayer(Entity);

#[derive(Component)]
#[relationship(relationship_target = CurrentPlayer)]
pub struct Player(Entity);

What alternative(s) have you considered?

Same as before but check if the entity is valid each time it is used.

[copygirl]

This would be addressed by #17485, right?

[Freyja-moth]

I'm not sure it would, that would only change how they're stored but (as far as I can tell) doesn't directly add relationships to resources.

[copygirl]

What do you mean "only change how they're stored"? When resources become components, they gain all the benefits that come with that, such as being able to make them relationships. At least I don't see why you shouldn't be able to write the exact code you used as an example. (Though not entirely sure what the example is trying to achieve. Does it "just" make Player a singleton component?)

[Freyja-moth]

They gain all the benefits that come with being stored as entities, that does not guarantee they will have all of the features of components.

You wouldn't be able to add required components to a resource, for example, because then it would no longer function as a resource.

From what I can tell no one has explicitly said that we should add relationships to resources after this change has been made, they've simply stated that it's an ecs feature that resources are missing.