Pre-RFC: Move references

[Soni]

@CAD97

And, importantly, a typestate changing reference is not a type itself, despite appearing in type position as if it were a type. As such, it cannot itself be stored in a binding, a generic type argument, or a field in an aggregate type, and cannot be composed upon; it is just usable as part of a function signature. [-- begin note: This is the biggest departure from current Rust semantics, what I dislike about C++'s design the most ((rvalue) references being not types (well, except that inasmuch as std::reference_wrapper still exists)), and I think the biggest flaw in this proposal. Not being manipulable as a type like everything else means that it sticks out as an alien, not first-class part of the language. "First class functions" aren't when a language has functions can do everything that functions can do, it's when functions are a type unto themselves that can be manipulated in bindings. I personally don't see a way to accomplish the goals of your proposal without a new non-type extension to function signatures, however. Plus, ideally, a typestate proposal would make fn(&mut T) and fn(&mut T->T) identical. The difference in drop responsibilities makes this impossible, though. end note --]

If it is possible to make it so you can put a PIT-move-reference in a type, have it sound, and have it ergonomic, then it should be done. We actually can think of a few ways to make it possible but they're all kinda weird/"alien"? Conceptually, the change of states is a part of function signatures, not types... but due to types also being part of function signatures there's nothing that should prevent merging the two it's just that it's gonna make things even weirder. But then again, functions are already a weird type...

(Also yeah, &mut T->T is not &mut T because one is actually a move reference. That's why we see value in having move references, they make a good first step for eventually having PITs with an unambiguous syntax. If specced correctly, they can add the ability to pass partially initialized values around in a forward-compatible way with PITs. This is, again, not gonna help with DerefMove (both because you can put things back into the Box, but more importantly also because you can Drop/panic after taking some things (but not others) out of the Box.), at least not on its own, but it seems valuable.)

[SkiFire13]

@tema2

What happens in details:

• callee moves out, gets a value, marks referred binding to be uninitialized
• process data (where panic can occur);
• move new value in referred binding, mark it to be initialized.

Panic handler can see referred binding in only one state : contain a value, but marked as unitialized => no Drop would be called for it.

As stated here not calling a destructor is not unsafe.

I don't think that in Rust we can go further in terms of correctness.

But what if the panic is catched by the caller? I remember discussing that possibility in this or the PITs' thread, but there's nothing related to that in the RFC draft.

Also, that seems an overly complicated machinery. Can't you just delegate all the responsibility for dropping on panics to the callee, avoiding the need for shared drop flags?

@tema2

arbitrary pointer may not be blindly casted to pretty safe by design reference

Note that arbitrary pointers just can't be cast to references, even in unsafe code. They can however be dereferenced and the reborrowed, which is an unsafe operation.

[tema2]

@CAD97

but I still don't see a reason why Send is directly problematic for &move inout _

What happens if a receiver thread got an obligated move reference, moved out and then did a panic? We just get one more source of broken obligations. Scoped threads have already run into similar issues.

[tema2]

@SkiFire13

That's not true. It's perfectly fine to move an !Unpin type if you have an &mut reference, so it must be safe if you have an &move T! , because it can be coerced into an &mut T .

 impl<P> DerefMove for Pin<P>
 where P: DerefMove,
{
 type Output = P::Output;

 fn deref(&move self!) -> &move Self::Output! {
   self.pointer
 }
}

This is unsound, &move Self::Output! can be coerced into an &mut Self::Output , so this would be the equivalent of making Pin::get_unchecked_mut a safe function.

Thanks for being watchful - I'll update coercion rules. They should be coercible only if underlying T is safe to move.

[CAD97]

@tema2

What happens if a receiver thread got an obligated move reference, moved out and then did a panic?

This has nothing to do with threads, though. catch_unwind terminates an unwind with no Send bound involved.

[SkiFire13]

@tema2

Thanks for being watchful - I'll update coercion rules. They should be coercible only if underlying T is safe to move.

Is there really a need for restricting the coercion rules? Can't you just add a <P as DerefMove>::Output: Unpin bound on the DerefMove impl for Pin<P> just like the impls of Deref and DerefMut?

[Soni]

we have to ask: what's the point of DerefMove on Pin?

[tema2]

Ofc, we can and probably should. But the point of !Unpin types is that their values shouldn't be moved (right?), we can enforce it for these references.

[SkiFire13]

@tema2

But the point of !Unpin types is that their values shouldn't be moved (right?)

They can't be moved after being pinned. Pin already prevents them from being moved, there's no reason to add additional constraints.

[tema2]

The Great Plan ™ was like:

• forbid moving values of a !Unpin types from a references;
• add an implementation of DerefMoves for Pin<P>;
• add a way of safe creation of such values. (&move in...);
• and have the references (this proposal) that allow natural work with unmovable values (generators, futures, more to come) that wouldn't need Pin<P> at all;
• forbid moving !Unpin values at all, like not only via references.

The last thing is not backward compatible and breakage might be big.

[carbotaniuman]

That seems undoable in practice due to backwards compatibility. And relitigating Pin is unlikely to win any support.

[comex]

Pin is due to be 'relitigated' to some extent, someday, so that it can be a real part of the language rather than relying on pin_mut and pin_project macros. But backward compatibility breaks are not the way to do it.

(And now is arguably not the time to do it. Though you could say that about everything being proposed here: if RFCed, it will just go to postpone purgatory. Doesn't mean we can't theorize.)

[robinm]

Sorry if this is obvious, but why do we need to be able to move temporarly out of a reference? I don't understand what &move inout provides. Can't we just have an &mut reference instead of &move inout? With &mut we can observe its content (instad of de-initilisating it), then write a new value (instead of re-initilisating it)?

[SkiFire13]

@tema2

The Great Plan ™ was like:

• forbid moving values of a !Unpin types from a references;
• add an implementation of DerefMove s for Pin<P> ;
• add a way of safe creation of such values. ( &move in ...);
• and have the references (this proposal) that allow natural work with unmovable values (generators, futures, more to come) that wouldn't need Pin<P> at all;
• forbid moving !Unpin values at all, like not only via references.

The last thing is not backward compatible and breakage might be big.

I don't understand what's the end goal here... Remove Pin? It would make sense if you would provide something with more value than Pin, but all you're doing is giving another name to Pin, which won't solve anything. All of this at the cost of creating useless differences between references. What would this allow you to do that a Pin<&move T> doesn't?

Edit: What about wrappers? You can wrap an !Unpin type in a wrapper and implement Unpin for the wrapper. Given that you can project an &move T to a field, this means that it's possible to get an &move T to the !Unpin field, which asserts it can't be moved, however you can later move the wrapper, thus moving the !Unpin type too and breaking the pin guarantees.

@robinm

With &mut we can observe its content (instad of de-initilisating it), then write a new value (instead of re-initilisating it)?

Sometimes you want to move out of it, do some work and then put back the value. The problem is that if a panic occurs when doing work then there's no value to put back.

[robinm]

@SkiFire13

Sometimes you want to move out of it, do some work and then put back the value.

I understand the drawbacks, but not the advantages. Why observing (and mutating) an &mut isn't sufficient? Why do you need to move out? (become moving back into it)

[SkiFire13]

@robinm

I understand the drawbacks, but not the advantages. Why observing (and mutating) an &mut isn't sufficient? Why do you need to move out? (become moving back into it)

For example if you have a function that has signature fn(T) -> T you won't be able to use it to map the value pointed by a &mut T.

[phlopsi]

@SkiFire13

The problem is that if a panic occurs when doing work then there's no value to put back.

Then what advantage does the RFC offer over

&mut Option<T>

Option does the necessary bookkeeping, if a panic occurs by having the drop flag be part of its type. If the RFC implementation does what Option does, but hides it, isn't that more of an argument against rather than in favor of the new reference type?

[SkiFire13]

@phlopsi

Then what advantage does the RFC offer over

&mut Option<T>

Option does the necessary bookkeeping, if a panic occurs by having the drop flag be part of its type. If the RFC implementation does what Option does, but hides it, isn't that more of an argument against rather than in favor of the new reference type?

• &mut Option<T> is not always possible to use.
• One of the aims of move references is making Box less special (or rather, allowing other types to be as special as Box) and that's not possible using a &mut Option<T>.

[tema2]

Decided to go with an auto-trait: rev. 5.

[Mokuz]

unsafe { self.ptr as &move T! }

feels a bit weird, shouldn't it be

unsafe { &move *(self.ptr as *move T!)! }