Skip to content

Possibility of exposing RcBox for transferring allocations between Box and Rc #1283

@glaebhoerl

Description

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-langRelevant to the language team, which will review and decide on the RFC.T-libs-apiRelevant to the library API team, which will review and decide on the RFC.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions