5 ms·

Pin applies to the pointer, !Move applies to the pointee.

by Georgelemental 3mo ago

ordu 3mo ago
So... Pin should be defined as Pin<T: !Move>?
- mcherm 3mo ago
  No, the point of Pin is to wrap types that CAN move. If the type were !Move then Pin wouldn't be needed.
  - simonask 3mo ago
    I guess `!Move` is largely equivalent to `Unpin` for the purposes of `Pin`, so for example Pin's safe constructor `Pin::new()` can be re-expressed in terms of `!Move` instead of `Unpin`. Today you need unsafe code to pin a `!Unpin` (i.e. "movable") type. But I also suspect there are important differences between `!Move` and `Unpin` that I'm not sure about.
    - stymaar 3mo ago
      This whole thread summarizes what's wrong with Pin: it's so confusing everyone in here got something wrong. (Just to address your mistake in particular Unpin is almost the opposite of !Move: it's the trait that represents things that can be un-pinned, that is: moved despite having been pinned. See https://doc.rust-lang.org/std/pin/index.html#unpin https://doc.rust-lang.org/std/pin/index.html#unpin).
      - simonask 2mo ago
        Right, of course. Yeah, it's an API riddled with so many double negatives it's hard to keep track.
  - Dagonfly 3mo ago
    > 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.
    - Mond_ 3mo 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 3mo 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 2mo 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 https://blog.yoshuawuyts.com/gen-auto-trait-problem
        stymaar 2mo ago
        Thanks for the explanation (though I have to admit I liked your old blog theme more). Since it's just a matter of how async get desugared, can it be changed through an edition?

Pin applies to the pointer, !Move applies to the pointee.

ordu 3mo ago

So... Pin should be defined as Pin<T: !Move>?

mcherm 3mo ago
No, the point of Pin is to wrap types that CAN move. If the type were !Move then Pin wouldn't be needed.
- simonask 3mo ago
  I guess `!Move` is largely equivalent to `Unpin` for the purposes of `Pin`, so for example Pin's safe constructor `Pin::new()` can be re-expressed in terms of `!Move` instead of `Unpin`. Today you need unsafe code to pin a `!Unpin` (i.e. "movable") type. But I also suspect there are important differences between `!Move` and `Unpin` that I'm not sure about.
  - stymaar 3mo ago
    This whole thread summarizes what's wrong with Pin: it's so confusing everyone in here got something wrong. (Just to address your mistake in particular Unpin is almost the opposite of !Move: it's the trait that represents things that can be un-pinned, that is: moved despite having been pinned. See https://doc.rust-lang.org/std/pin/index.html#unpin https://doc.rust-lang.org/std/pin/index.html#unpin).
    - simonask 2mo ago
      Right, of course. Yeah, it's an API riddled with so many double negatives it's hard to keep track.
- Dagonfly 3mo ago
  > 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.
  - Mond_ 3mo 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 3mo 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 2mo 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 https://blog.yoshuawuyts.com/gen-auto-trait-problem
        stymaar 2mo ago
        Thanks for the explanation (though I have to admit I liked your old blog theme more). Since it's just a matter of how async get desugared, can it be changed through an edition?