Rust project goals: Immobile types and guaranteed destructors
1–10 of 112 posts
Re: Rust project goals: Immobile types and guaranteed destructors
#2Could someone explain this to me as someone who's never touched async Rust? What kind of useful patterns would this allow for?
Re: Rust project goals: Immobile types and guaranteed destructors
#3More algebraic effects being retrofitted onto Rust.
Re: Rust project goals: Immobile types and guaranteed destructors
#4Could someone explain this to me as someone who's never touched async Rust? What kind of useful patterns would this allow for?
It makes it easier to write recursive async functions. It makes it easier for async functions to borrow rather than clone from their outer scope.
All really awesome, non controversial and ergonomic things.
Re: Rust project goals: Immobile types and guaranteed destructors
#5Could someone explain this to me as someone who's never touched async Rust? What kind of useful patterns would this allow for?
The big one is scoped tasks, or structured concurrency.
Currently, Rust has scoped threads: Threads that are guaranteed to terminate before the function that spawned them returns. This is powerful because it allows you to pass references to data that lives on your own stack to threads that you spawn, without any bookkeeping or synchronization mechanism - just the normal borrow checker rules.
For example, you can allocate a large array, then split it into multiple non-overlapping slices, and then have a group of threads populate each slice, all in safe Rust code.
But the same isn't true for async tasks in Rust, because futures are just objects representing a state machine, and they don't get any special treatment. In particular, they carry no guarantee that the state machine will actually run to completion, which is fundamentally different from how functions run (stack frames are guaranteed to unwind in some way, either by returning or panicking, unless the entire program has terminated).
To make the situation worse, there are many cases where Rust futures are much more prone to cancellation than synchronous code, because that is also one of the big benefits of using async in the first place - for example, you may be running multiple futures in parallel, pick the result from the one that finishes first, and then cancel the rest.
Getting this stuff under control is why people say that "async cancellation" is a difficult problem to solve, and that is true in all languages that have async. These traits will hopefully make it much easier to work with in Rust.
(There are also many other interesting things you could do with this, unrelated to async. Immovable and unforgettable are both interesting properties of an object that could be used to design many cool APIs in general.)
Re: Rust project goals: Immobile types and guaranteed destructors
#6mem::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?
Re: Rust project goals: Immobile types and guaranteed destructors
#7mem::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?
By doing the same as with `Sized`: Automatically including the `Forget` bound on generic parameters and letting methods that don't need to be able to forget them opt out. That way existing code continues to compile and existing unsafe code doesn't become unsound.
Re: Rust project goals: Immobile types and guaranteed destructors
#8Great new! Since 2016 or so it became apparent that immovable types were a crucial missing part of Rust, but for a long time it was believed it wouldn't be possible to add them without breaking everything, which is why we ended up with the Pin hack.
I'm very glad they found a way to add it eventually, as it's really filling a glaring hole in the language.
Re: Rust project goals: Immobile types and guaranteed destructors
#9Although not part of the goal, it also mentions `!Destruct`/"must-move types", aka linear types: Instead of there always being a way to drop values without providing any arguments, if you wanna get rid of a value of a linear type you have to call a function that takes it by value.
Re: Rust project goals: Immobile types and guaranteed destructors
#10mem::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 .