3 ms·
I muuuch prefer pin to any move trait. Pin is a place property, not a type property. I think this post covers it nicely. https://without.boats/blog/pinned-place
by conradludgate 2y ago
I muuuch prefer pin to any move trait. Pin is a place property, not a type property. I think this post covers it nicely. https://without.boats/blog/pinned-places/ https://without.boats/blog/pinned-places/. It definitely should be more ergonomic though
- simonask 2y agoI don't know. In spite of Boats' great points, I think the programmer intuition definitely aligns more with it being a type property, in the sense that it enables the most interesting use case: self-referential values. All of that interacts badly with move semantics, and especially the lack of "guaranteed copy elision", but nevertheless...
- josephg 2y agoAuthor here. The first draft of this post spent a lot more time talking about Move. But I think the real question is: What syntax would let us author self-referential types. And, in a way that doesn't require Box-ing everything. (Rust's mantra is abstraction without overhead.) But then I thought about it more. Whatever you call it - Pin or Move - the point is to say "this struct contains a borrowed field". But we never needed Pin for local variables in functions - even when they're borrowed - because the borrow checker understands whats going on. The "Pin" is implicit. Pin also doesn't describe all the other semantics of a borrowed value correctly - like how borrowed values are immutable. I suspect if the borrow checker understood the semantics of borrowed struct fields (just like it does with local variables), then we might not need Pin or Move at all.