libextra: Add a copy-on-write arc container.

[ghost]

This allows patch adds a new arc type that allows for creation of copy-on-write data structures. The idea is that it is safe to mutate any data structure as long as it has only one reference to it. If there are multiple, it requires cloning of the data structure before mutation is possible.

[alexcrichton]

Interesting! We've had a number of copy-on-write proposals in the past, but this is certainly clean and well written.

Code-wise, the only comment I have is that a Freeze bound is probably still needed to allow safe sharing of read-only data.

Content-wise, I'm a little in favor of this, but others should weigh in as well. We're still planning on dissolving libextra at some point, but this might make a nice addition for the arc module regardless.

[pcwalton]

You definitely need a Freeze bound. Otherwise not only could anyone mutate the data, an evil clone method that doesn't do the right thing could cause data races.

[ghost]

I have updated CowArc to use the Freeze trait and rebased the changes.

[bill-myers]

I don't think it makes sense to have both Arc and CowArc.

Arc and Rc can and should have copy-on-write functionality themselves directly (of course the cow-related functions will have tighter kind bounds including Clone).

Pull request #9786 does exactly that (it probably needs to be rebased though).

[flaper87]

I agree with @bill-myers here. I'd prefer having this within Arc and Rc. Perhaps as a separate Trait being implemented by both.

@bill-myers will you've time to update your PR? It was closed due to inactivity.

[ghost]

The core of copy-on-write is so trivial it could could easily be turned into a trait and implemented by Arc and Rc.

Something like this (which I have not tried to compile):

trait CopyOnWrite<T> {
    /// check to see if there is one reference to the container
    fn is_owned(&self) -> bool;

    /// clone the data self points to, then modify self to point
    /// to point to the newly cloned data.
    fn to_owned(&mut self);

    /// get a mutable reference to the data self points to. 
    /// if the data structure is shared with multiple pointers
    /// clone the data first, and return a reference to the cloned data
    fn cow_get_mut(&mut self) -> &'a mut T {
        if !self.is_owned {
            self.to_owned();
        }
        unsafe { &mut *self.get() }
    }
}

The factor that stops this from being feasible right now is that there is no standard way in rust to get a reference from a Rc, Gc, Arc ect. I know there was talk about having a Byref trait that would allow boxes to be interchangeable in some cases. In the current state, there is no nice way to build this.

[glaebhoerl]

Iterating that further, how about:

trait MaybeOwned<T> {
    fn maybe_get_mut<'s>(&'s mut self) -> Option<&'s mut T>;
}

trait CopyOnWrite<T>: MaybeOwned<T> {
    fn cow_get_mut<'s>(&'s mut self) -> &'s mut T;
}

It's worth separating maybe_get_mut which can be implemented for any T from cow_get_mut which usually requires T: Clone (which will be present as a bound on the impls). Do is_owned and to_owned have a reason to exist as separate methods? They're just specializations of maybe_get_mut and cow_get_mut where you ignore the returned &mut.

I put zero thought into names, please do come up with better ones. CopyOnWrite itself might be the wrong idea, because it can be trivially implemented for unique pointers without any copying involved.

[ghost]

The semantic that eveyone keeps coming to is CloneWhenShared which is a really bad name but does better describe what we are doing. The big advantage of the name CopyOnWrite it is the keywords people expect when they are looking for a COW functionality. But I agree, the name should probably be clearer.

I like the Traits @glaebhoerl drew up here. They are simple enough that they could be implement without the Deref trait.

[glaebhoerl]

An interesting question here: if Rc gains copy-on-write (mutate-if-not-shared) capabilities, would it have to be non-Freeze? (Seems like it would.)

[thestinger]

It can use &mut self and inherit mutability from the single owner.

[alexcrichton]

I have added this to the meeting agenda (a bit overdue perhaps!)

[glaebhoerl]

@thestinger Not what I meant. Its contents are loaned out as &mut, that's not in doubt. What I'm trying to point out is that Rc<T> itself would no longer count as deeply immutable, i.e. Freeze, precisely because its contents can be mutated in this way.

[thestinger]

The Freeze bound means it inherits mutability (freezable) or is immutable, not that it's always immutable.

[glaebhoerl]

Oh, right, of course. My bad.