<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 Feb 25, 2017, at 11:41 AM, plx via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">1: Collection Composition</div><div class=""><br class=""></div><div class="">As much as the high-level picture is focused on safety, I’d just like to request a strong focus on making sure the eventual ownership system addresses the common issues like avoiding copies when mutating through optionals, or when nesting collections, and so on.</div></div></div></blockquote><div><br class=""></div>Avoiding copies is basically the entire core of the proposal. The interaction with safety is that sometimes copies are necessary to avoid memory unsafety, and this proposal recommends an approach that minimizes that.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Point fixes like the custom `.values` collection on `Dictionary` that just got approved are useful, but hopefully ownership can provide a general solution.</div><div class=""><br class=""></div><div class="">2: Mutating Iteration & Granularity</div><div class=""><br class=""></div><div class="">If I understood the mutating-iteration section right it reads as if `for inout` would only be available on `MutableCollection`. Is that correct?</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">If so that does seem limiting, as e.g. for a `Dictionary` it’d be nice if something like this were expressible:</div><div class=""><br class=""></div><div class=""> for (key, inout value) in someDictionary {</div><div class=""> }</div><div class=""><br class=""></div><div class="">…assuming there’s not some insurmountable technical obstacle.</div></div></div></blockquote><div><br class=""></div>The technical obstacle to this is just that, so far, we've tried to make language features like for-loops use formal protocols.</div><div><br class=""></div><div>An iteration protocol is going to have requirements like this:</div><div> generator iterate() -> Element</div><div> mutating generator iterateMutable() -> inout Element</div><div>But there's no valid substitution that makes '(Key, inout Value)' equal either 'Element' or 'inout Element'. So we'd have to do some special to make this work.</div><div><br class=""></div><div>That said, no, there's no intrinsic technical reason this can't be made to work.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">3: Mutable Views</div><div class=""><br class=""></div><div class="">Currently a major pain point of Swift has been exposing “mutable views” into a type in a reasonable way. Apologies for length, but here’s an extended example:</div><div class=""><br class=""></div><div class=""> /// Implements a 2D grid (of size fixed upon initialization).</div><div class=""> /// **Not** a `Collection` itself but has many *views* into it that *are* `Collection`s.</div><div class=""> ///</div><div class=""><div class=""> struct Grid2D<T> {</div><div class=""> // typical CoW backing storage</div><div class=""> fileprivate var storage: Grid2DStorage<T></div><div class=""> </div><div class=""> /// Obtain a linear traversal of our grid:</div><div class=""> /// - parameter corner: The corner at which we start (e.g. `northWest`)</div><div class=""> /// - parameter motion: The order in which we travel (`latitudeThenLongitude` or `longitudeThanLatitude`)</div><div class=""> ///</div><div class=""> /// - returns: A read-only `Collection` that visits each grid location in `self`, following the requested traversal</div><div class=""> func traversal(from corner: Grid2DCorner, following motion: Grid2DMotion) -> Grid2DTraversal<T></div><div class=""> }</div></div><div class=""><br class=""></div><div class="">…wherein `Grid2DTraversal<T>` is, as noted, a "read-only view” into its parent that also adopts `Collection`.</div><div class=""><br class=""></div><div class="">What would be nice is to be able to make that `Grid2DTraversal<T>` into a mutable view in a way that’s also *safe*; what I mean is something like:</div><div class=""><br class=""></div><div class=""> extension Grid2D {</div><div class=""> </div><div class=""> mutating func mutatingTraversal<T>(from corner: Grid2DCorner, following motion: Grid2DMotion, _ mutator: (inout Grid2DTraversal<T>) -> R) -> R {</div><div class=""> var t = self.traversal(from: corner, following: motion)</div><div class=""> return mutator(&t)</div><div class=""> }</div><div class=""><br class=""></div><div class=""> }</div><div class=""><br class=""></div><div class="">…with the specific goals of (a) having mutations applied via `Grid2DTraversal` get directly written-through to the underlying storage (w/out pointless copying) but also (b) making `Grid2DTraversal` generally act safely in all other contexts.</div><div class=""><br class=""></div><div class="">As it is the “best” way to squeeze this into the type system at this time is arguably:</div><div class=""><br class=""></div><div class="">- define Grid2DTraversal:</div><div class=""> - to have as a strong reference to the backing storage</div><div class=""> - as only having the read-only methods</div><div class="">- *also* define MutableGrid2DTraversal:</div><div class=""> - to have an unowned reference to the backing storage</div><div class=""> - also include the mutating methods</div><div class=""><br class=""></div><div class="">…and then just be careful with API design and patterns of use; in particular only provide access to `MutableGrid2DTraversal<T>` values in the context of closures passed into dedicated functions like `mutatingTraversal`, above…and then just be disciplined never to extract those passed-in values.</div><div class=""><br class=""></div><div class="">Needless to say this isn’t a very satisfactory state of affairs—it is well into “why am I bothering with all this?” territory—and it’d be *far* nicer if the ownership system would allow for `Grid2DTraversal`:</div><div class=""><br class=""></div><div class="">- to adopt `Collection` without restriction</div><div class="">- to adopt `MutableCollection` only in certain ownership contexts</div><div class="">- to have reasonable control over where those contexts apply </div></div></div></blockquote><div><br class=""></div>It's not sensible to have a type that conditionally conforms to a protocol based on context. However, the requirements of MutableCollection are all 'mutating', so you can't actually use them unless you have a mutable value. So the way to fit what you're asking for into the ownership proposal is to make sure that clients of your view type only have a mutable value when the base was mutable, and the easiest way of getting that is to have the view be vended as storage rather than a return value. If you think about it, a mutable view can't be an independent value anyway, because if code like this could work:</div><div><br class=""></div><div> var grid = ... // note that this is mutable</div><div> var view = grid.traversal(from: p, following: m) // should return a mutable view by design, right?</div><div> view.mutate() // reflected in grid, right?</div><div><br class=""></div><div>then it completely destroys the value-type properties of 'grid', because 'view' should really be an independent value.</div><div><br class=""></div><div>The proposal suggests doing this instead with storage, so that the view is logically a (mutable) component of the grid. So on the use side:</div><div><br class=""></div><div> var grid = ...</div><div> inout view = &grid[traversingFrom: p, following: m]</div><div> view.mutate()</div><div><br class=""></div><div>and on the declaration side:</div><div><br class=""></div><div> struct Grid2D<T> {</div><div> subscript(traversingFrom corner: Grid2DCorner, following motion: Grid2DMotion) -> Grid2DTraversal<T> {</div><div> read {</div><div> yield Grid2DTraversal(...)</div><div> }</div><div> modify {</div><div> var traversal = Grid2DTraversal(...)</div><div> yield &traversal</div><div> // ensure changes were applied here</div><div> }</div><div> }</div><div> }</div><div><br class=""></div><div>If you feel that the aesthetics of this leave something to be desired, that's a totally reasonable thing to discuss.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Anyways, it’s not clear to me, personally, whether or not the above is within the scope of any likely, concrete ownership system that’d follow from the manifesto or not…but if at all possible I’d prefer the eventual ownership system make it reasonable—and reasonably safe—to implement “small-c ‘collection’s that can safely-and-efficiently expose various *mutable* views as big-C `Collection`s”.</div><div class=""><br class=""></div><div class="">Apologies if all of the above considerations have answers that follow trivially from the manifesto; it’s just unclear personally whether the features described in the manifesto would work together to allow something like the above to be implemented more-reasonably than currently the case.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 11:08 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class="" style="margin: 15px 0px;"><div class="">On Feb 17, 2017, at 4:50 AM, Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">adrian.zubarev@devandartist.com</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p class="" style="margin: 15px 0px; -webkit-margin-before: 0px;">Hi John, would you mind creating a markdown document for this manifesto in<span class="Apple-converted-space"> </span><a href="https://github.com/apple/swift/tree/master/docs" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none; -webkit-margin-before: 0px;">https://github.com/apple/swift/tree/master/docs</a>? :)</p><div class=""><br class="" style="-webkit-margin-before: 0px;"></div></div></div></div></blockquote>Yes, it should go in the repository. That commit is pending, but the in meantime, you can see the document properly rendered at:</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> <a href="https://github.com/rjmccall/swift/blob/4c67c1d45b6f9649cc39bbb296d63663c1ef841f/docs/OwnershipManifesto.md" class="" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;">https://github.com/rjmccall/swift/blob/4c67c1d45b6f9649cc39bbb296d63663c1ef841f/docs/OwnershipManifesto.md</a></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><font face="Helvetica Neue, Helvetica, Arial, sans-serif" class="">John.</font></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>