4 ms·
Does this mean that you can't take unique/mutable references to the inside of reference-counted objects? Is there no escape hatch, like Rust's RefCell?
by pcwalton 7y ago
Does this mean that you can't take unique/mutable references to the inside of reference-counted objects? Is there no escape hatch, like Rust's RefCell?
- WalterBright 7y agoYou can, it's just that the RC object itself cannot be implemented with the @live checking on. The RC object can then present itself with a @live compatible interface.
- qznc 7y agoHow does that look like? Do I annotate it as @undead?
- WalterBright 7y agoWhile I like your style, in D we do it with @trusted annotations.
- fluffything 7y agoSo you can call code that's not annotated with borrow checking annotations from code that is ?
- WalterBright 7y agoYes.
- fluffything 7y agoSo how do you guarantee that the caller invariants are upheld, e.g., that the unannotated code does not leak a pointer to a different thread, etc. ?
- mntmoss 7y agoHow do you do that in unsafe Rust?
- WalterBright 7y ago> So how do you guarantee that the caller invariants are upheld You can't, you have to trust the user. That's why one tries to minimize calling non-@live code.
- pcwalton 7y agoI still don't understand how that works. How do you avoid having two unique, mutable references to the same value in that case? For example (pseudocode): void f(shared_ptr<Foo> a, shared_ptr<Foo> b) { g(&mut *a.field, &mut *b.field); } This is unsafe because a and b might point to the same object.
- complistic 7y agoThat is what the part of this idea that Walter is tackling first, See https://github.com/dlang/DIPs/blob/master/DIPs/DIP1021.md https://github.com/dlang/DIPs/blob/master/DIPs/DIP1021.md The short of it is that the compiler will enforce that the same pointer is not provided to function more then once at the call site.