Pin projection with lots of language support

[dlight]

@Jules-Bertholet

One concern I've always had with !Move proposals is that in many cases, "immovable" values can—and often must—be moved at some point. For example, a self-referential future may be moved into an executor spawn function before being polled. The Pin model handles this quite elegantly.

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

[withoutboats]

(NOT A CONTRIBUTION)

@comex

I don't want to derail the thread, but generally speaking, !Move should be paired with some form of in-place construction. That could be in the form of "placement by return" or something more explicit. In-place construction is a highly-requested feature even for movable structs because of its performance benefits. But with !Move, such a feature would be necessary in order to construct things that should never move at all. This should also generally be sufficient for futures.

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.

@josh

If we can manage to simplify pinning and provide linear types with the same change, that'll be wonderful.

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

[withoutboats]

(NOT A CONTRIBUTION)

@comex

(Or if in-place Future construction isn't enough and you really need to move them, then the design could be combined with the recent "async is IntoFuture, not Future" proposal: the IntoFuture object could be movable while the Future object is not.

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.

[josh]

@withoutboats

A bizarre remark. Move has no connection to linear types,

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

[withoutboats]

(NOT A CONTRIBUTION)

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.