5 unstable releases

new 0.2.0 Nov 15, 2024
0.1.3 Jul 22, 2024
0.1.2 Jul 15, 2024
0.1.1 Jun 24, 2024
0.0.0 Dec 6, 2023

#2178 in Game dev

Download history 130/week @ 2024-07-29 137/week @ 2024-08-05 79/week @ 2024-08-12 186/week @ 2024-08-19 155/week @ 2024-08-26 134/week @ 2024-09-02 125/week @ 2024-09-09 149/week @ 2024-09-16 224/week @ 2024-09-23 185/week @ 2024-09-30 103/week @ 2024-10-07 292/week @ 2024-10-14 344/week @ 2024-10-21 125/week @ 2024-10-28 230/week @ 2024-11-04 361/week @ 2024-11-11

1,103 downloads per month
Used in 7 crates (via godot-core)

MPL-2.0 license

60KB
1K SLoC

Internal crate of godot-rust

Do not depend on this crate directly, instead use the godot crate. No SemVer or other guarantees are provided.

Contributor docs

A re-entrant cell implementation which allows for &mut references to be reborrowed even while &mut references still exist.

This is done by ensuring any existing &mut references cannot alias the new reference, and that the new reference is derived from the previous one.

This emulates rust's system for function calls. i.e my_func(&mut borrowed) creates a second &mut reference inside the function.

Instead of directly using the concept of aliasing pointers, we use the term accessible instead. A reference (or other pointer) to some value is considered accessible when it is possible to either read from or write to the value it points to without using unsafe. Importantly, if we know that a reference a is inaccessible, and then we create a new reference b derived from a to the same value, then we know for sure that b won't alias a. This is because aliasing in rust is based on accesses, and if we never access a then we cannot ever violate aliasing for a and b. And since b is derived from a (that is, b was created from a somehow such as by casting a to a raw pointer then to a reference b), then a won't get invalidated by accesses to b.

Dependencies

~0–620KB
~11K SLoC