Hacker News

> 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.

10000truths 4 hours ago [ - ]

> 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.

You could model this with a state machine enum where the "stay put" phase is a variant that accepts a !Move, like so:

  enum StateMachine<PinnedState: ?Move> {
      InitialState,
      State1(String),
      State2(Box<PinnedState>),
      TerminalState,
  }

Mond_ 5 hours ago [ - ]

Stupid question, can't this trivially be solved by having a movable constructor / builder type that then gets turned into a non-movable type when built?

Dagonfly 3 hours ago [ - ]

Sure, thats one reason why IntoFuture and Future exist. Imo, in hindsight this is also main mistake in aysnc Rust: The whole async system should be build around IntoFuture rather than Future (async fn should return impl IntoFuture).

That way you could pass around IntoFutures without being affected by auto traits leaking. Only when you actually call .await() or .poll() would the immovable Future materialize.

yoshuaw an hour ago [ - ]

You're right that this is an important issue. I wrote a post explaining this in some detail, so at the very least we avoid having the same problem with generator functions:

https://blog.yoshuawuyts.com/gen-auto-trait-problem