Possibility of exposing RcBox for transferring allocations between Box and Rc

[glaebhoerl]

The idea occasionally comes up of whether Rc could take ownership of a Box and re-use the allocation, or conversely of converting a uniquely-owned Rc into a Box. While logically intuitive, this runs up against the physical limitation that Rc stores the reference counts inline in the allocation, ahead of the data, and so the two would not be compatible as-is. Making Rc store the reference counts out of line in a separate allocation (like std::shared_ptr) doesn't seem to be worth the overhead just to support this case.

If, however, we were to consider the ability to avoid some allocations in this way important enough, we do have a fairly straightforward option available to us to support it in some cases: publicly expose the RcBox type which comprises an Rc allocation (without necessarily providing access to the internal RcBox of any Rc - just the type). Something like this:

#[derive(Copy, Clone)]
pub struct RcBox<T: ?Sized> {
    strong: Cell<usize>, // private
    weak:   Cell<usize>, // private
    pub value: T
}

impl<T> RcBox<T> {
    pub fn new(value: T) -> RcBox<T> { ... }
}

impl<T: ?Sized> Rc<T> {
    pub fn from_box(source: Box<RcBox<T>>) -> Rc<T> { ... }
}

pub fn try_into_box<T: ?Sized>(self: Rc<T>) -> Result<Box<RcBox<T>>, Rc<T>> { ... }

(By keeping the reference count fields private, we can ensure that the reference count of any RcBox not currently inside of an Rc is always 1, so that from_box doesn't even need to check or reset them.)

[bluss]

@eddyb Has some ideas for how custom allocator support can make this easier, without having to expose anything.

[eddyb]

That would be #1138.

[glaebhoerl]

Even cooler :)

[le-jzr]

Why not make the (current) RcBox #repr(C) and put strong and weak fields after the data? That way, we could simply realloc the box with strong possibility of reusing the original memory. It's not guaranteed, but it would be much better than current state with no drawbacks.

[eddyb]

after the data
Doesn't work with DSTs, which both Rc and Arc support.

[eddyb]

Errr, GitHub, I didn't want to do that!

[le-jzr]

after the data

Doesn't work with DSTs, which both Rc and Arc support.

Ah, right. Although I'm sure that could be worked around with some raw pointer shenanigans. But that would invalidate the "no drawbacks" part, because of much uglier implementation. :-/