Storing extra data at relationship components is too easily lost

[urben1680]

You are able to store extra data at relationships like this:

#[derive(Component)]
#[relationship(relationship_target = Parent)]
pub struct Child {
    #[relationship]
    parent: Entity,
    pub data: u8, // Relationship data
}

#[derive(Component)]
#[relationship_target(relationship = Child)]
pub struct Parent {
    #[relationship]
    children: Vec<Entity>,
    pub data: u8, // RelationshipTarget data
}

The data is initialized with Default but can be later modified by the user.

However, it can easily happen to lose the data and have it reset to it's default value. Because of this, the user cannot rely on the value to be preserved unless the relationship remains untouched from then on.

In the following I try to maintain a list of ways where I've seen this can happen. Please help me by pointing out what I forgot, or add to it yourself if you are a maintainer.

• RelationshipData data
  • EntityWorldMut methods do not automatically overwrite Relationship components #19601
• RelationshipTarget data
  • Preserve extra data in RelationshipTarget with replace_related(_with_difference) #19588

[Dampfwalze]

Today I found myself using a std::marker::PhantomData inside a relation, since I want to distinguish the relation based on a tag type (Child<Tag1> and Child<Tag2> are unrelated to each other and can safely overlap). This use case would currently be impossible when the extra data would be removed.

#[derive(Component)]
#[relationship_target(relationship = Child<T>)]
struct Parent<T: Send + Sync + 'static> {
    #[relationship]
    children: Vec<Entity>,
    _phantom: PhantomData<T>,
}

#[derive(Component)]
#[relationship(relationship_target = Parent<T>)]
struct Child<T: Send + Sync + 'static> {
    #[relationship]
    parent: Entity,
    _phantom: PhantomData<T>,
}

[urben1680]

Hmm what data would be lost with that? PhantomData contains no data. When you overwrite a Child<Foo> with another Child<Foo>, then no data is lost. Can you maybe show a bit of code, maybe a failing test that makes the issue more obvious?

[Dampfwalze]

As I understand, you are proposing to completely remove the ability to have multiple fields on a relationship component (using the #[relationship] annotation). That would break my use case, since I could not add the PhantomData field. Then the compiler would complain about the unused T.

[urben1680]

Ah now I understand.

Right, that proposal in particular would force you to have as many individual relationship pairs as you currently have types for that generic.

But I currently explore a different solution as ideally we fix this issue without removing the ability to store extra fields.

EDIT: removed the general solutions section as it does not reflect the present approach.