Local<T> declares coarse mutable access

[farnoy]

Having two distinct systems use Local<T> (for the same T) creates a dependency between them. I believe this is due to the mutable access being declared the same way for ResMut<T> as with Local<T>.

bevy/crates/bevy_ecs/src/resource/resource_query.rs

Lines 281 to 285 in 3bc5e4c

	fn access() -> TypeAccess {
	let mut access = TypeAccess::default();
	access.mutable.insert(TypeId::of::<T>());
	access
	}

bevy/crates/bevy_ecs/src/resource/resource_query.rs

Lines 322 to 326 in 3bc5e4c

	fn access() -> TypeAccess {
	let mut access = TypeAccess::default();
	access.mutable.insert(TypeId::of::<T>());
	access
	}

Is there a way to make this more granular and remove dependencies between such systems?

[fu5ha]

You can newtype-wrap whatever the data is that you want to store in a Local<>

The intended use case is pretty thin -- basically making a struct that is specific only that one system which you want to store state in.

[cart]

I agree that a newtype is a quick fix for this (and it will work with the current Bevy releases). But I also think we might be able to solve this problem by just removing the T access entirely (and the borrow locks). The instance of the type is guaranteed to be uniquely accessed by the system, so theres no need to synchronize here. The only way to get an aliased reference is to directly access the Resources collection, which can only happen from a "thread local system" (which is guaranteed to have unique Resources access).

[farnoy]

That is what I ended up doing, yeah.

I think TypeAccess should be extended with Option<SystemId>. The actual access is already scoped by that parameter, IMO it's confusing that hazard inspection doesn't know about it.

[memoryruins]

Resolved by #864