[swift-dev] copy-on-write proposal

[Joe Groff]

> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev <swift-dev at swift.org> wrote:
> 
> This is a proposal for representing copy-on-write buffers in SIL. Actually it’s still a draft for a proposal. It also heavily depends on how we move forward with SIL ownership.
> <CopyOnWrite.rst>
> If you have any comments, please let me know.

The SIL-level design seems sensible to me at a glance. At the language level, I think it would make more sense to treat this as an attribute on class types rather than on properties in structs using the class. I don't think many people reuse class definitions as both shared reference types and as value type payloads, but beyond that, I think that making it an attribute of classes would put us into a better position to leverage the borrow model to enforce the "mutable-only-when-unique" aspect of COW implementations. John alluded to this in the "SIL address types and borrowing" thread:

> I wonder if it would make more sense to make copy-on-write buffer references a move-only type, so that as long as you were just working with the raw reference (as opposed to the CoW aggregate, which would remain copyable) it wouldn't get implicitly copied anymore.  You could have mutable and immutable buffer reference types, both move-only, and there could be a consuming checkUnique operation on the immutable one that, I dunno, returned an Either of the mutable and immutable versions.
> 
> For CoW aggregates, you'd need some @copied attribute on the field to make sure that the CoW attribute was still copyable.  Within the implementation of the type, though, you would be projecting out the reference immediately, and thereafter you'd be certain that you were borrowing / moving it around as appropriate.

If 'copy-on-write' were a trait on classes, then we could distinguish unique and nonunique references to the class. A unique reference would act like a move-only type to prevent accidental loss of uniqueness. We can also allow a copy-on-write class to have "mutating" methods, and only allow mutation on unique references. It seems to me like, exploring this direction, we could also come up with a way for the high-level value-semantics operations on the struct to statically indicate which methods are known to leave the value's buffers in a unique state, or which return values that are uniquely owned, which would give the optimizer more ability to avoid uniqueness checks across calls without relying on inlining and IPO.

-Joe