<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Mar 6, 2017, at 3:46 PM, Karl Wagner <<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks very much for writing this up, it’s very interesting.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Courier" class="">struct CollectionWrapper<C: Collection> {</font></div><div class=""><font face="Courier" class=""> var _underlying: C</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class=""> init(contentsOf other: C) where C: RangeReplaceableCollection { </font></div><div class=""><font face="Courier" class=""> _underlying = C();</font></div><div class=""><font face="Courier" class=""> _underlying.replaceSubrange(_underlying.startIndex..<_underlying.endIndex, with: other) </font></div><div class=""><font face="Courier" class=""> }</font></div><div class=""><font face="Courier" class="">}</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class="">// Would love to do this…</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class="">extension CollectionWrapper {</font></div><div class=""><font face="Courier" class=""> init(contentsOf other: C) where C: ValueSemantics { </font></div><div class=""><font face="Courier" class=""> _underlying = other </font></div><div class=""><font face="Courier" class=""> }</font></div><div class=""><font face="Courier" class="">}</font></div></blockquote><div class=""><br class=""></div><div class="">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”)?</div></div></div></blockquote><div><br class=""></div></div>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.<div class=""><br class=""></div><div class="">John.</div></body></html>