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

Rust project goals: Immobile types and guaranteed destructors

github.com

Post reply on HN
Print view View original

41–50 of 112 posts

Re: Rust project goals: Immobile types and guaranteed destructors

#41

Post by klauserc »

stymaar wrote: post #10
OskarS wrote: post #6

mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that? Isn’t that why mem::forget is safe, because you can always implement it yourself safely? How do you get around that?

> mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that? But there's an easy solution for that: you make the reference-counted smart pointers require their pointee type to be Forget . It will be like how Arc doesn't implement Send unless .

An alternative way to "forget" a value is to hand it off to another thread that then loops infinitely.

Could of course be plugged by saying `!Forget : !Send`, but wouldn't that preclude legitimate useful scenarios for `!Forget`?

Re: Rust project goals: Immobile types and guaranteed destructors

#42

Post by orlp »

germandiago wrote: post #38

Little by little, Rust, like D, acknowledges that C++ flexibility regarding object construction, copy and move, even if too much as a default, is sometimes needed :) I saw in D years ago how they also checked into this flexibility after getting some use cases for it (in this case, copying): https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1...

This is the opposite, it is further opting out of flexibility.

Re: Rust project goals: Immobile types and guaranteed destructors

#43

Post by aw1621107 »

klauserc wrote: post #41
stymaar wrote: post #10

Earlier quoted context omitted.

> mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that? But there's an easy solution for that: you make the reference-counted smart pointers require their pointee type to be Forget . It will be like how Arc doesn't implement Send unless .

An alternative way to "forget" a value is to hand it off to another thread that then loops infinitely. Could of course be plugged by saying `!Forget : !Send`, but wouldn't that preclude legitimate useful scenarios for `!Forget`?

> An alternative way to "forget" a value is to hand it off to another thread that then loops infinitely.

Might be able to address that by only allowing such a handoff to a thread spawned via some scoped abstraction to ensure that progress can only be made if/when the spawned thread terminates?

Re: Rust project goals: Immobile types and guaranteed destructors

#45

Post by Guvante »

Tazerenix wrote: post #40
dubi_steinkek wrote: post #26

Earlier quoted context omitted.

How so? This feel distinct from the "algebraic effects"-like features like constness, async, can-panic, can-unwind, etc., since this is a property of the types themselves rather than of functions.

The traits are essentially effect handlers for effects like `drop `, `move `, `forget ` which are implicitly charged to the a function which owns a `T` and does drops, moves, or forgets it. Inferring the capabilities of the function from the traits of the types of the arguments is similar to tracking effects. The function charges `drop ` when `x: T` goes out of scope, which is handled by the trait implementation. If…

I haven't seen any algebraic effects system that is that powerful

The closest is linear types but even then drop isn't an effect but also a function you can call to allow not continuing the references

Re: Rust project goals: Immobile types and guaranteed destructors

#49

Post by eqvinox »

orlp wrote: post #42
germandiago wrote: post #38

Little by little, Rust, like D, acknowledges that C++ flexibility regarding object construction, copy and move, even if too much as a default, is sometimes needed :) I saw in D years ago how they also checked into this flexibility after getting some use cases for it (in this case, copying): https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1...

This is the opposite, it is further opting out of flexibility.

I guess the point is that the concepts are needed, which is true. But the Rust way (more explicit and targeted) of dealing with these concepts seems better than how either C++ or D handle it.

Re: Rust project goals: Immobile types and guaranteed destructors

#50

Post by Dagonfly »

mcherm wrote: post #34
ordu wrote: post #30

Earlier quoted context omitted.

So... Pin should be defined as Pin ?

No, the point of Pin is to wrap types that CAN move. If the type were !Move then Pin wouldn't be needed.

> the point of Pin is to wrap types that CAN move.

I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place.

Pin allows for that by tying the object to the place only when required. That's why Pin relates to both the object and the place.

Meanwhile, !Move types can't ever move. The object has to remain in the inital place it was constructed in. !Move requires in-place construction and emplacement to be ergonomic at all.

Post reply on HN