undefined

points

[-]

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.

by ameliaquining4 hours ago|

parent|

[-]

My sense of sentiment in the project right now is that people want to keep the invariant that assignment (to an ordinary memory location) is always just a memcpy and never calls arbitrary user-defined code, because if that code does something unexpected, debugging (at least if a human's doing it) is likely to be hampered by the syntactic invisibility of the call site. This is why the most obvious ergonomic-reference-counting proposal (have a trait that lets types opt into implicit clones) ran aground, and they're now experimenting with (conceptually clunkier, in my opinion) alternatives that aim to make reference counting ergonomic but still syntactically visible.

So if Rust ever gains move constructors, you'll probably have to call them explicitly, the way you have to explicitly call .clone(). (There's actually already a third-party library that does something like this (https://docs.rs/moveit), and I think Crubit is using a similar API to let Rust code call C++ move constructors.)