mutability of ResMut

[ghost]

I have just started looking into bevy and I'm curious about some design choices that don't seem to be explained in the docs. Here's one regarding ResMut. My understanding is that Res and ResMut are pointer types. Normally, in Rust mutability of the pointer and the value pointed to are separate concepts, this is true for Box, Rc or plain references. However, it seems that ResMut needs to be declared mut itself to be useful, such as here:

bevy/examples/ecs/timers.rs

Line 50 in 97d8e4e

fn countdown_system(time: Res<Time>, mut countdown: ResMut<Countdown>) {

What is the rationale behind this design?

[DJMcNab]

Your assertions that you don't need mut to edit the value behind a Box are false:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=48e8e1d406dcb157dc29800d28058d0a

Basically, it's like this because it's impossible for us to not require this; at least without reverting to runtime borrow checking (in the style of RefCell), which would be stupid. Ideally we'd be able to tell rustc that our types are 'inherently mutable' like &mut T, but there's no mechanism to do this in the language.

(Your comment about Rc is weird, since Rc only gives immutable access to the target value, unless you use make_mut, but that also requires the Rc is mut)

[ghost]

Clearly, I'm confused. Perhaps it would help if you could explain why, in the light of what you said, it is necessary to have Res and ResMut as separate types. Couldn't we have just Res with res: Res referring to an immutable resource and mut res: Res referring to a mutable one?

[DJMcNab]

It is impossible for us to use such a scheme without either disabling parallelism for resource access (in which case taking the resource immutably is not a useful capability) or falling back to a form of runtime borrow checking (which again, would be stupid)

That is, there is no way for us to tell the difference between res: Res<T> and mut res: Res<T>. Consider that it's trivial to transform from one 'form' to the other, simply using a let statement.

I don't want this to be required, but without support from the compiler I don't think there's anything we can do about it.

[ghost]

Thanks, I think I'm starting to see what I was getting wrong. I guess I'm still hung up on C++'s unique_ptr and shared_ptr.