3 ms·
Yeah, it's a self-enforced contract that objects of type Gc<T> are only ever touched by the virtual machine, but I get your point.
by ltungv 2y ago
Yeah, it's a self-enforced contract that objects of type Gc<T> are only ever touched by the virtual machine, but I get your point.
- adrian17 2y agoThe issue is that it's a simple footgun as soon as you start adding non-trivial native methods (say, string methods, array.map etc). The only way to make sure that they don't exist is removing the DerefMut impl entirely. It's not just that it's possible to break the code, but that lack of any checks makes it impossible to detect at either compile-time or runtime and have it "appear to work". One way to solve it to remove the DerefMut implementation and have it work more like Rc - as in, the user is forced to write `Gc<Cell<T>>` or `Gc<RefCell<T>>` if they want mutability. This solves the aliasing borrows issue at the cost of extra runtime checks with RefCell (and still doesn't prevent you from unsoundly calling `sweep()` while holding a Gc)
- ltungv 2y agoI implemented exactly what you were saying here (https://github.com/ltungv/rox/commit/6a611e7acb3b36d0a3a4376f36b1774d7c032ad2#diff-6ec61590e2fd8e76c30e8f6fafef37660f5750b5f229775ad008e79945d71f2c https://github.com/ltungv/rox/commit/6a611e7acb3b36d0a3a4376...). But where's the fun in that?