upvote

points

by stymaar13 hours ago |
comments
upvoteby q3k11 hours ago|
[-]
> I'm very glad they found a way to add it eventually

Will this integrate with existing code that uses Pin<T>? If not this will split the ecosystem even further...

reply
upvoteby ameliaquining4 hours ago|
parent|
next
[-]
They recognize that there's going to have to be some kind of compatibility or migration story for existing APIs based on Pin, but have decided to punt that question to next year. For now, the focus is on the non-async-related use cases for these new language features (for which Pin is already insufficient); once those are known to work, then they'll shift focus to letting the async ecosystem benefit too.
reply
upvoteby ordu10 hours ago|
parent|
prev|
[-]
I don't see why it may fail to integrate. Declare Pin as !Move and... thats all? I mean, there will be issues, edge-cases because it is just how these things happen, but still I don't see any fundamental issues with continuing to use Pin.
reply
upvoteby afdbcreid1 hours ago|
parent|
next
[-]
Like others said, Pin is incompatible with these semantics. Some people argue, though, that we need both (basically because pinned types can be moved before being pinned).
reply
upvoteby Georgelemental9 hours ago|
parent|
prev|
next
[-]
Pin applies to the pointer, !Move applies to the pointee.
reply
upvoteby ordu9 hours ago|
parent|
[-]
So... Pin should be defined as Pin<T: !Move>?
reply
upvoteby mcherm8 hours ago|
parent|
[-]
No, the point of Pin is to wrap types that CAN move. If the type were !Move then Pin wouldn't be needed.
reply
upvoteby Dagonfly7 hours ago|
parent|
next
[-]
> 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.

reply
upvoteby 10000truths2 hours ago|
parent|
next
[-]
> 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,
  }
reply
upvoteby Mond_3 hours ago|
parent|
prev|
[-]
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?
reply
upvoteby Dagonfly2 hours ago|
parent|
[-]
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.

reply
upvoteby simonask8 hours ago|
parent|
prev|
[-]
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.

reply
upvoteby stymaar2 hours ago|
parent|
[-]
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).
reply
upvoteby mahirsaid3 hours ago|
parent|
prev|
[-]
Give it some time and see how people will use it and problems emerging. I do feel that this will stay.
reply