Documentation for the inability to .read() and .write() to the same signal / ArenaItem

[ActuallyHappening]

Hey community,
I recently encountered a panic that went something like this:

let db: RwSignal<_> = DbState::from_context();
let state = db.read();
if state.is_user() {
  db.write().logout();
}
move || match state {}

But this paniced because it said that the signal was already disposed when I called .write(). I was holding a read guard over this .write() call. Why is this limitation in place? Is it because the &mut reference is directly to the backing arena, and the the guards job is only to change some metadata, so to maintain no-mutable-aliasing you have to enforce no concurrent immutable + mutable guards?

If that is so, I do understand it now, but upon first reading the leptos book and various pieces of documentation in reactive_graph I never saw this behaviour documented. I guess my question is this: Did other people automatically assume that would can't .write() and .read() the same signal? And can this be documented as a panic condition in the leptos book / top level documentation of reactive_graph, or is it so obvious?

And also, in debug builds, can this error message be a bit more precise if the mutable/immutable borrow counts are kept track of?

[gbj]

It is explicitly documented in the book, granted that .write() is used in several examples prior to this section:

.write() returns a write guard which is a mutable reference to the value of the signal, and notifies any subscribers that they need to update. Note that you cannot read from the value of the signal until this guard is dropped, or it will cause a runtime error.

I think it's also more or less intuitive given Rust's general "shared-xor-mutable" approach to references. You can think of a signal as just as fancy RefCell if it's helpful: like other interiorly-mutable types, it will panic if you try to mutate it while also holding a read-lock on it.

Your example is even shorter in the working version:

let mut state = db.write();
if state.is_user() {
  state.logout();
}

[ActuallyHappening]

huh ok, I just missed that thanks ;)