> 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. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
