Pin projection with lots of language support

It seems like this could be solved by the typestate pattern: values are created at a type that can be moved, and then converted to a type that can't be moved.

edit: for futures, I think this is the same as the "async is IntoFuture, not Future" proposal that was mentioned



All Move proposals I've seen define Move as only limiting movement after the first time the address is taken, which side-steps these issues and avoids this additional requirement.

A bizarre remark. Move has no connection to linear types, you seem confused about what these terms mean.

1 Like


Using typestate like this instead of using the "after first address of" definition would probably work, but obviously introduces its own additional complexity. An interesting facet of this design is that it if it weren't for thread locals (boo!) it would allow for !Send state inside of futures, like matklad has written about.

More generally, the decision to use the Pin design was made under the circumstances of Rust in 2018/2019; there was no chance of adding a Move trait at that time, especially not in time to ship async/await before Mozilla ultimately stopped funding Rust. I doubt there would be nearly as many well-paid sinecures for Rust contributors if Rust didn't have async/await syntax when that happened, so I don't think this was the wrong decision. But it's obvious that the platonic ideal of Rust would have a Move trait of some kind, not Pin, for exactly the reason you identified: it composes better because every interface doesn't need to be modified to support it. The two worst offenders here are Iterator and Drop.

As you've also identified though the big problem is getting there from here. I think the only chance of any sort of Move trait happening is as a packaged deal with some definition of linear types (whether undroppable or unforgettable), so that the pain is reduced because these two fundamental shifts are being made together. This obviously can't happen in 2024, and if anyone wants it to happen in 2027 they should start working on the problem now. It will be the biggest change since 1.0, and every edition it's missed it gets more and more unrealistic.


I said precisely what I meant, albeit evidently with too much brevity. There would be value in using a uniform mechanism to handle both linear types (can move but can't Drop) and pinned types (can't move, can Drop, but some proposals I've seen may want a variant on Drop). This was in particular meant to contrast with to other variations on linear type proposals, which use entirely different mechanisms (e.g. linear fn).



If all you mean is that you think linear types should be distinguished from affine and normal types through a marker trait, obviously that is the correct solution. It's already how affine and normal types are distinguished (normal types implement Copy). Blog post ideations about linear fn are fully nonsensical.