[swift-dev] copy-on-write proposal

[Dave Abrahams]

on Thu Oct 13 2016, Joe Groff <swift-dev-AT-swift.org> wrote:

>> 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, 

Foundation does, or would if they could.

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

+1

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

That's pretty cool.  However, I think there's nothing to prevent any
mutating method from storing a copy of self in a global, so I think we'd
need some participation from the programmer (either an agreement not to
do that, or an explicit claim of uniqueness on exit) in order to
identify operations that create/preserve uniqueness.

-- 
-Dave