News for hackers. Stuff that matters.

A comment on Unsoundness in Pin. Parent comment

Re:Unsoundness in Pin by steveklabnik on Friday November 29, 2019 @12:05PM (#21665464)
We can go back to the reason that Pin even exists in the first place. With Rust, you create a computation, and it implements the Future trait. When you want it to execute, you give it to an executor. This often moves the data structure that represents the computation to the heap, so that it has a stable address, and can continue running after the current stack frame is over. So, before the future starts executing, it can be moved around in memory (and probably will at least one time), but after it starts executing, it must never move again.

Does that make sense?

[ Parent | on HN ]
Re:Unsoundness in Pin by jimmaswell on Friday November 29, 2019 @12:53PM (#21665776)
So the main use is convenience to seamlessly make stack variables permanent? Intuitively that doesn't sound worth the language design troubles compared to making the programmer declare these things on the heap manually. I'm not that familiar with Rust though.
[ Parent | on HN ]
Re:Unsoundness in Pin by steveklabnik on Friday November 29, 2019 @01:02PM (#21665826)
That’s one use case, it’s not the only one. And it’s not always “put it on the heap”, so you can’t solve the issue that way.
[ Parent | on HN ]
Re:Unsoundness in Pin by kibwen on Friday November 29, 2019 @02:37PM (#21666319)
Ideally it should be possible to avoid the heap entirely; futures in Rust should be capable of operating even in contexts that don't come with a memory allocator, such as memory-constrained embedded devices.
[ Parent | on HN ]