[ajross]

Also worth pointing out that the specific problem area, highly optimized runtimes for interpreted/JIT-compiled languages, the borrow checker doesn't really have much to offer. Rust's safe memory paradigm more or less requires an "owner" for every pointer, and by definition the arbitrary graph of pointers in the executed code aren't going to have that. Any such runtime is going to be built on a metric ton of unsafe.

[aapoalas]

I would argue that this is trying to fit a square peg in a round hole: The JS objects should not be considered "owners" for each other in the Rust ownership sense. The Isolate / heap uniquely owns all items within it: The arbitrary graph of "references" between objects are merely data for the garbage collection algorithm and keys that can be used to get items from the heap. They have no real way to actually access the item "pointed to" by the reference directly. All access must go through the Isolate (at least in a lifetime sense).

This would allow writing the system with either very little or no unsafe code (depending on the accessing method and heap structure chosen), and Rust's borrow checker would actually correctly tell you that you cannot hold an Array's buffer borrowed while calling some unknown function because the function can mutate anything in the heap and thus needs to take exclusive access to it.

EDIT: Also note that V8's "sandboxed pointers" access all already goes through the Isolate indirectly: All compressed pointers as part of their decompression use a "base" pointer. The same could be written (with unsafe) in Rust in such a way that the "base" pointer is the heap pointer that carries all ownership of the heap, and now decompressing pointers would be equal to taking a borrow of the whole heap.