Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Group Borrowing: Zero-cost memory safety with fewer restrictions

verdagon.dev

Post reply on HN
Print view View original

11–20 of 87 posts

Re: Group Borrowing: Zero-cost memory safety with fewer restrictions

#11

Post by littlestymaar »

skywal_l wrote: post #4
kibwen wrote: post #2

> In any language, when we hand a function a reference to an object, that function can't destroy the object, nor change its type This isn't quite true. While Rust doesn't currently support this, people have proposed the concept of `&own` references that take ownership of the object and free it when the reference goes out of scope (consider that Rust's standard destructor signature, `fn drop(&mut)`, should probably ta…

I don't understand your comment. `drop` takes a *mutable* reference. But by default, references in Rust are immutable.

shared references are immutable in Rust, mut references and shared references are both references.

Re: Group Borrowing: Zero-cost memory safety with fewer restrictions

#12

Post by littlestymaar »

kibwen wrote: post #2

> In any language, when we hand a function a reference to an object, that function can't destroy the object, nor change its type This isn't quite true. While Rust doesn't currently support this, people have proposed the concept of `&own` references that take ownership of the object and free it when the reference goes out of scope (consider that Rust's standard destructor signature, `fn drop(&mut)`, should probably ta…

Intriguing, what would be the purpose of such owning references compared to just passing ownership? Is that to have a way to reliably avoid memcopying large objects when passing them by value?

Re: Group Borrowing: Zero-cost memory safety with fewer restrictions

#13

Post by wavemode »

mrkeen wrote: post #7

> Because of those "inaccessible" rules, we can never have a readwrite reference and a readonly reference to an object at the same time. I can't not see this as a good thing. It's almost at the level of "the only thing an ownership system does". If my thread is operating on a struct of 4 int64s, do I now have to think about another read-only thread seeing that struct in an invalid partially-written state?

Ideally, the rules for single-threaded references and references that are allowed to be shared across threads would be different.

Re: Group Borrowing: Zero-cost memory safety with fewer restrictions

#14

Post by wavemode »

kibwen wrote: post #2

> In any language, when we hand a function a reference to an object, that function can't destroy the object, nor change its type This isn't quite true. While Rust doesn't currently support this, people have proposed the concept of `&own` references that take ownership of the object and free it when the reference goes out of scope (consider that Rust's standard destructor signature, `fn drop(&mut)`, should probably ta…

An &own reference seems like it would just be equivalent to a Box.

Re: Group Borrowing: Zero-cost memory safety with fewer restrictions

#15

Post by Ygg2 »

skywal_l wrote: post #4
kibwen wrote: post #2

> In any language, when we hand a function a reference to an object, that function can't destroy the object, nor change its type This isn't quite true. While Rust doesn't currently support this, people have proposed the concept of `&own` references that take ownership of the object and free it when the reference goes out of scope (consider that Rust's standard destructor signature, `fn drop(&mut)`, should probably ta…

I don't understand your comment. `drop` takes a *mutable* reference. But by default, references in Rust are immutable.

Kibwen is saying that there was an idea to have `fn drop(&mut x)` from Drop trait become `fn drop_own(&own x)`. Then `&own` would do mutation and drop the owner of the reference. A regular &mut reference shouldn't do that outside of `drop(&mut x)`.

Re: Group Borrowing: Zero-cost memory safety with fewer restrictions

#16

Post by zozbot234 »

wavemode wrote: post #13
mrkeen wrote: post #7

> Because of those "inaccessible" rules, we can never have a readwrite reference and a readonly reference to an object at the same time. I can't not see this as a good thing. It's almost at the level of "the only thing an ownership system does". If my thread is operating on a struct of 4 int64s, do I now have to think about another read-only thread seeing that struct in an invalid partially-written state?

Ideally, the rules for single-threaded references and references that are allowed to be shared across threads would be different.

That's why Cell and RefCell are a thing. Both allow you to mutate shared references, but disable shared access across threads. The qcell crate even includes a version of Cell/RefCell that's "branded" by a region/lifetime, just like in this proposal.

Re: Group Borrowing: Zero-cost memory safety with fewer restrictions

#17

Post by modulared »

kibwen wrote: post #2

> In any language, when we hand a function a reference to an object, that function can't destroy the object, nor change its type This isn't quite true. While Rust doesn't currently support this, people have proposed the concept of `&own` references that take ownership of the object and free it when the reference goes out of scope (consider that Rust's standard destructor signature, `fn drop(&mut)`, should probably ta…

> I believe that languages with typestate can cause types to change as a result of function calls

Do you have any specific languages?

Re: Group Borrowing: Zero-cost memory safety with fewer restrictions

#18

Post by kibwen »

littlestymaar wrote: post #12
kibwen wrote: post #2

> In any language, when we hand a function a reference to an object, that function can't destroy the object, nor change its type This isn't quite true. While Rust doesn't currently support this, people have proposed the concept of `&own` references that take ownership of the object and free it when the reference goes out of scope (consider that Rust's standard destructor signature, `fn drop(&mut)`, should probably ta…

Intriguing, what would be the purpose of such owning references compared to just passing ownership? Is that to have a way to reliably avoid memcopying large objects when passing them by value?

> Is that to have a way to reliably avoid memcopying large objects when passing them by value?

I believe so, yes. Currently the only way to transfer ownership is by-value, and LLVM might optimize away the memcpy, but also it might not.

Re: Group Borrowing: Zero-cost memory safety with fewer restrictions

#19

Post by sirwhinesalot »

I had a somewhat related idea to this which was simply to track reference stability (i.e., is there any operation beyond freeing the data outright that will invalidate them).

A reference into a vector is unstable so you can only have 1 mut xor N read. A reference into an arena is stable so you can have all the muts you want, but they cannot be sent across threads.

Reference to object vs reference to contents is also related, you can safely have multiple mut references to the same object that cannot invalidate each other, even if they invalidate references to the contents.

This can be tracked with path analysis as employed by Hylo (Hylo only has second class references, but I mean the algorithm they use to track paths is applicable).

Post reply on HN