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