[krukah]

Another great WithoutBoats writeup. Admittedly, this is one of those corners of Rust that I'm glad is abstracted away and buried in async runtime internals.

That said, I'm curious if/when/why/how anyone uses Pin<T> outside of a custom Future implementation?

[etra0]

I am curious about this as well.

The way it's phrased it makes me understand a bit that it could be used within FFI, like if you get a pointer from a extern function that returns a *mut T, I could have better semantics by wrapping it with Pin<&mut T>, but then it says

"Another fact about the pinned typestate is that for most types it is completely irrelevant. If the value of type can never contain any self-references, pinning it is useless"

Mind you I'm very new at FFI but I'd like to understand what are the best ways to wrap them into safe Rust.

[ComputerGuru]

Ffi: you have a c api that exposes an item by ptr not by ref so it mustn't be moved.

Interacting with system types that rely on their address. Eg I think std uses a pin equivalent for mutex/futex on some operating systems because the kernel docs say the userland lock object must not change its address after initialization (even when not locked, which is normally the only condition and doesn’t need Pin because you can’t move something that has a reference to it).