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

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.

▲

Georgelemental 2 hours ago | parent [-]

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

▲

ordu 2 hours ago | parent [-]

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

▲

mcherm an hour 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.

	▲	Dagonfly 4 minutes 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.
	▲	simonask an hour 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.