Consider reliable variants of Mutated, Added and Changed flags

[Davier]

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

Currently the Mutated, Added and Changed flags are cleared at the end of each frame. This means that they can only be observed by systems that are scheduled after the change. It is also impossible AFAIK for two systems to both detect each other's changes.
While the upcoming upgrade in scheduling will make it easier to order systems, it would still be useful to have a reliable variant of these flags for cases where same-frame detection is not required (or even as a prototyping tool).

What solution would you like?

We could change the ComponentFlags from:

bitflags! {
    pub struct ComponentFlags: u8 {
        const ADDED = 1;
        const MUTATED = 2;
    }
}

to:

bitflags! {
    pub struct ComponentFlags: u8 {
        const ADDED = 1;
        const JUST_ADDED =  2;
        const MUTATED = 3;
        const JUST_MUTATED =  4;
    }
}

(Of course the naming is subject to debate).
When a component is added/mutated, the JUST_X are set. At the end of the frame, the struct would be updated with: (flags & 0b00001010) >> 1 instead of being cleared. The following query transformers would exist:

• JustAdded<T>, JustMutated<T> and JustChanged<T> as the instantaneous but unreliable versions (the current existing flags)
• Added<T>, Mutated<T> and Changed<T> as reliable but next-frame versions

What alternative(s) have you considered?

We could keep the current state as is, and require to either order system correctly or use events.

Additional context

The memory footprint would not change since ComponentFlags is a u8 already. It would be slightly more expensive to update flags at the of the frame, and querying Changed would require and additional bit mask. Thus I expect the performance impact to be very low. I plan to implement and benchmark it.

[Ratysz]

Related/duplicate of #68?

[Davier]

Related/duplicate of #68?

Sorry for missing that. I think that the suggestions at the end of that issue are close to what I am proposing here actually.

Should I copy everything to there and close this issue?

[Ratysz]

It's not my call, but I think that'd be best, yes.