> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev 
> <swift-dev@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.

swift-dev mailing list

Reply via email to