Library-level by-move reference

1

As a side project to unsized rvalues, I published an experimental crate refmove that provides by-move reference types.

https://crates.io/crates/refmove

This is the realization of my Pre-RFC posted some time ago, but has one new design idea: anchoring for by-move borrowing.

In this crate, you will need a two-step method call to borrow by-move:

42.anchor().borrow_move()

The first method takes 42 by value and produces something similar to Some(42). The second method takes Some(42) by mutable reference, takes the ownership and returns a by-move reference. I think it’s necessary because we need to insert a flag and drop hook at the caller side to ensure the validity of the memory region.

Anyway, it basically overlaps with unsized rvalues in its purpose but has both upsides and downsides. I’d like to share this prototype to compare these approaches.

2 Likes
2

Correct me if I’m wrong… this is like a glorified std::unique_ptr from C++, insofar as the style of move semantics (nullify whatever is moved from, instead of making it inaccessible).

3

That’s true. It imposes an additional “only once something” contract other than that of types. The problem is, if we want to ensure “only once borrowing”, then we need &move T, which is exactly what I want to emulate here.

A similar contract is used in Future::poll: it can be called only once, except for calls that returned Pending.

4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.