Migrate `component_reads_and_writes`

[BenjaminBrienen]

Migrate component_reads_and_writes for the 0.16 release. bevy uses it internally and it is deprecated.

It is being made pub(crate) in #16338. didn't work because it is used in an example. That fact makes this a 0.15 issue :)

[alice-i-cecile]

This was deprecated in #15207.

@chescock @pcwalton @SkiFire13, I'm not immediately sure on the migration strategy here. Bevy uses this internally in a few places, and the dynamic example uses it at

bevy/examples/ecs/dynamic.rs

Line 156 in e155fe1

.component_reads_and_writes()

I like the enum approach suggested here by @chescock personally.

[SkiFire13]

Note that the dynamic example was kinda broken before as well, as it didn't support the case where entity can access all components.

Short term I think the enum approach is the best one, but long term I agree with @pcwalton that this is an abuse of Access and shouldn't be exposed like this. I would instead prefer to see an API that allows you to get the list of components on an entity, and the list of components that are accessible on a FilteredEntity{Ref,Mut}.

I would also consider reworking the dynamic example, since it makes a lot of unsafe assumptions that in practice will not be true (e.g. that all the components that the FilteredEntityRef has access to will be of the custom kind the example creates)

[chescock]

Short term I think the enum approach is the best one, but long term I agree with @pcwalton that this is an abuse of Access and shouldn't be exposed like this.

How is it an abuse? I see Access as a kind of set, and iterating the elements of a set doesn't seem any worse than asking whether it contains a given element.

I do agree that fn component_reads_and_writes(&self) -> (impl Iterator<Item = T> + '_, bool) is bad! But I think it's bad because it leaks the implementation details of how unbounded sets are represented, and returning an enum would clean that up.

[SkiFire13]

How is it an abuse? I see Access as a kind of set, and iterating the elements of a set doesn't seem any worse than asking whether it contains a given element.

I'm ok with just exposing iteration over all components included in this set. But exposing how the set is defined (i.e. by inclusion or exclusion of some element) exposes implementation details.

I do agree that fn component_reads_and_writes(&self) -> (impl Iterator<Item = T> + '_, bool) is bad! But I think it's bad because it leaks the implementation details of how unbounded sets are represented, and returning an enum would clean that up.

I don't see the difference between that function and an enum, both leak the implementation details in the same way. An enum would just be a bit more ergonomic.

[bushrat011899]

#16348 provides one possible way forward. The general idea is to provide a higher level abstraction with fallibility in mind. That extra height allows the implementation details of Access to change while still providing a method that should be flexible enough to adapt.