> On Mar 6, 2017, at 4:30 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > on Mon Mar 06 2017, John McCall <[email protected]> wrote: > >>> On Mar 6, 2017, at 3:46 PM, Karl Wagner >>> <[email protected]> wrote: >>> Thanks very much for writing this up, it’s very interesting. >>> >>> The one thing which I think needs improvement is the Copyable protocol. I >>> think that this is >> actually part of a larger problem in Swift, which is that we don’t expose >> enough information to >> generic code for it to operate safely. This goes back to people asking for a >> value-equivalent to the >> “class” or “AnyObject” magic protocols. >>> >> >>> For example, often you would like to wrap a Collection and keep some >>> information about what it contains. In order to do that generically, you >>> need to ensure a client can hand you an exclusive view of a collection’s >>> contents, so you know they will not mutate underneath your feet. >>> >>> Currently, that means you need a RangeReplaceableCollection because it >>> includes an empty initialiser which allows you to create a unique copy of >>> the Collection’s contents. It’s a workaround, but it means we have this >>> unnecessary protocol requirement in the standard library, and in the >>> implementation, which is making copies that may not be required. If my >>> CollectionWrapper is initialised with something which has ValueSemantics, I >>> don’t need to create a whole new instance with equal contents to ensure >>> exclusivity of those contents. If this was an Array, for example, I could >>> simply assign it and it would ensure the underlying contiguous buffer is >>> never mutated. >>> >>> struct CollectionWrapper<C: Collection> { >>> var _underlying: C >>> >>> init(contentsOf other: C) where C: RangeReplaceableCollection { >>> _underlying = C(); >>> >>> _underlying.replaceSubrange(_underlying.startIndex..<_underlying.endIndex, >>> with: other) >>> } >>> } >>> >>> // Would love to do this… >>> >>> extension CollectionWrapper { >>> init(contentsOf other: C) where C: ValueSemantics { >>> _underlying = other >>> } >>> } >>> >>> As the proposal notes (with the File example), these are semantic >>> considerations which go beyond simple struct/class distinctions: >>> structs may have reference semantics, and classes may have value >>> semantics. Would it be possible to model Copyable/move-only in terms >>> of two new protocols, ValueSemantics and ReferenceSemantics, with >>> trivial types/non-trivial types given appropriate defaults >>> (overridable by the programmer, such as for “File”)? >> >> Class types have reference semantics and are still copyable; ownership >> is not going to change that. More generally, I don't see how anything >> we can do in ownership could ever do something like eliminate the >> possibility of a reference-semantics collection from the language. > > I think it might not be very related to ownership, but the use of the > word “Copyable” may be a problem. For most programmers when applied to > reference types “Copyable” will connote “Clonable,” i.e. that the > referent (rather than the reference, which is what you're referring to > when you say class types are copyable) can be explicitly copied. So I'm > betting Karl read “Copyable” and was led to this other topic which is of > concern to many people. In that sense, claiming “Copyable” for > ownership without also addressing “Clonable” could be a problem. > > The idea behind “Clonable” would be that it gives you a *generic* way to > create a logically *independent* copy of a value, that would work both > for value types and reference types.
That's a very fair point. John. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
