Hacker News new | past | comments | ask | show | jobs | submit
simonask | on: Rust project goals: Immobile types and guaranteed destructors
I agree with most of that, but there's one important detail (that I'm sure the designers of this proposal are thinking about): The current contract of Pin in Rust (the only standard support for expressing immobility) doesn't just cover the object's own location, but also any references derived from the object, commonly called "pin projection".

For example, if you have a `Pin<Box<Vec<u8>>>`, it's safe to turn that into a `Pin<&mut [u8]>`.

Any system that replaces `Pin` will probably have to maintain that same property, which wouldn't naïvely happen using C++-like move semantics, right? Or maybe I'm overassuming?

safercplusplus | parent
Hmm, I'm not sure if you're concerned about the "norad"-style run-time checked references I'm imagining or raw references. In either case, the property we (and `Pin<>`) are concerned about is whether an object can be (destructively) moved. You're pointing out a reference derived from a pinning reference essentially inheriting the pinning property. (I.e. the property that the target won't be inappropriately (destructively) moved.)

But with this proposal, the property that the object won't be (destructively) moved is (solely) a property of the object's type. Specifically, it doesn't depend on any property of any reference to the object, and certainly not on any other reference that that reference was derived from, right?

> Any system that replaces `Pin` will probably have to maintain that same property

Maybe any system that compatibly replaces `Pin`. Maybe. But I'm not sure that this proposal is overly concerned with compatibility with `Pin`. That github page explicitly mentions the desire to deprecate `Pin`, right? And like I suggested, if successful enough, it's conceivable that it could end up de facto deprecating Rust's necessarily-trivial-destructive moves in general. Conceivably.

loading story #49158709