`Mut`/`ResMut` mutable access without triggering change detection

[NathanSWard]

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

There are a set of uses cases where a user may want to mutably access some type that implements change detection (e.g. Mut) without actually triggering change detection.

What solution would you like?

An API exposed for these type e.g. get_untracked() or something like that which returns a &mut T to the inner type but does not cause is_changed() to return true.

What alternative(s) have you considered?

Using unsafe primitives UnsafeCell, or wrapping them in something like a Mutex to get mutable access immutably. However, these are quite a bit overkill and add unnecessary unsafe and overhead.

[TheRawMeatball]

Something else quite similar to this would be a map function, for getting a tracked mutable reference to a field on an object.

[mockersf]

This feels like an easy footgun to avoid fixing a bad resource modelling

[NathanSWard]

This feels like an easy footgun to avoid fixing a bad resource modelling

Sure I can see this as being a potential footgun, however there are steps you can take to avoid this. E.g. not automatically exporting the associated trait, adding docs etc...

(Edited comment to only include relevant info for this issue)

[NathanSWard]

Something else quite similar to this would be a map function, for getting a tracked mutable reference to a field on an object

Ohh I actually like this more.
Instead of

fn get_untracked(&mut self) -> &mut T;

do

fn bikeshedding(&mut self, f: impl FnOnce(&mut T));

[mockersf]

As I still disagree on your assessment on the State issue, I also disagree on how we should fix it 😄

For disabling change detection, its cost is very light, even more so on resource. And to get completely free of it you would also have to disable it on the system

Something that I could find interesting is having a way to disable change detection on a field at the struct declaration

#[derive(Resource)]
struct MyResource {
    field1: u8,
    #[resource(untracked)]
    field2: u8
}

[alice-i-cecile]

Something that I could find interesting is having a way to disable change detection on a field at the struct declaration

This is a much more interesting route IMO: it allows bypassing in an explicit way, defined on the struct itself. You can get the same effect with interior mutability, so I prefer the explicitness of @mockersf proposal.

I really don't like the idea of allowing consumers to make changes in an untracked way: it seriously violates the guarantees provided in a way that seems virtually impossible to debug since it could be occurring anywhere in your code base.

[NathanSWard]

I really like the API of #[resource(untracked)] @mockersf :)
This definitely adds quite a bit of complexity to the implementation though.

I really don't like the idea of allowing consumers to make changes in an untracked way: it seriously violates the guarantees provided in a way that seems virtually impossible to debug since it could be occurring anywhere in your code base.

I don't think is necessarily a valid argument though against allowing users the ability to do so.
I'm not saying we encourage users to do this, however, we shouldn't prohibit this finer level of control.
And it's not anywhere in your code base, it's only where you explicitly use the get_unchecked method.

#[derive(Resource)]
struct MyResource {
    field1: u8,
    #[resource(untracked)]
    field2: u8
}

This is ideally something we'd want not just for Resources though?
We should probably support this for Components as well.

[alice-i-cecile]

Agreed: this should work for components (and relations) too.

[TheRawMeatball]

Hmm, while the macro approach looks interesting, I'm not sure how we can implement it. The only thing I can think of is generating a trait and implementing it on Mut to add a acessor method that bypasses triggering change detection, but this causes a massive footgun where using field access instead of a method call suddenly re introduces change detection, and generating a trait fully implicitly is also rather ugly IMO. Furthermore, implementing this approach would require a full bypass anyways. So, I think we should just add the simple bypass now, and consider the much more complicated macro version after #2254 lands.

[jakobhellermann]

Having a way to mutably access a struct without change detection is very useful in bevy-inspector-egui. Since egui expects e.g. &mut f32 for a slider widget, you have to give out a mutable reference which makes change detection not work.

To fix that I compied the Mut implementation and added get_mut_silent and mark_changed functions:
https://github.com/jakobhellermann/bevy-inspector-egui/blob/3a0fd8970df3337a069778ecbeee47db7cd30961/src/plugin.rs#L242-L254.

This usecase wouldn't be solved by #[resource(untracked)].