<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 22, 2016, at 1:53 PM, plx 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">On the one hand I like the idea (and particularly like the foundation types having meaningful `mutating` annotations, loosely speaking).</div><div class=""><br class=""></div><div class="">On the other hand I have two questions:</div><div class=""><br class=""></div><div class=""><div class="">1. will the NS types actually remain visible/usable (on supported platforms, perhaps requiring a specific import to become visible)?</div></div></div></div></blockquote><div><br class=""></div><div>NSData will still exist and be available (as will NSMutableData) on all platforms including swift-corelibs versions; there are still some reasons to have reference semantics from time to time hence why the proposal did not take away any of them.</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=""><div class="">2. does this include — or are their separate plans for — exposing the backing reference type in some principled way? </div></div></div></div></blockquote><div><br class=""></div><div>`as` cast will grant a reference type, but of course this has a potential of a copy semantic. A direct access to the underlying box that contains the object would be dangerous; in that references passed around for that container would be beyond the scope of data’s control (Tony might be able to speak on this a bit more than myself)</div><div><br class=""></div><div>The structure may later drop it’s reference to that object and construct a new version upon mutation etc.</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=""><div class="">For (2.) what I mean is something like having at least the heavyweight thing like `Data` (and ideally also Array/Set/Dictionary/IndexSet, etc.) have matching-API reference types like `DataRef` in the standard library. </div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>let dataStructure = Data(bytes: someBytes, count: 5)</div><div>let dataReference = dataStructure as NSData // this is a reference version of the structural container, but you should not count on the identity since the structure could mutate out and replace the backing storage.</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=""><div class=""><br class=""></div><div class="">I think this has come up before at some point, but if it did I didn’t follow it.</div></div><div class=""><br class=""></div><div class="">My interest in (1.) is mostly b/c I suspect the answer to (2.) is “no”.</div><div class=""><br class=""></div><div class="">Apologies if these are alrexdy-addressedd and I just missed it.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Apr 22, 2016, at 12:18 PM, Tony Parker 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dear swift-evolution denizens,<div class=""><br class=""></div><div class="">As you know from our announcement of Swift Open Source and our work on naming guidelines, one of our goals for Swift 3 is to “drop NS” for Foundation. We want to to make the cross-platform Foundation API that is available as part of swift-corelibs feel like it is not tied to just Darwin targets. We also want to reinforce the idea that new Foundation API must fit in with the language, standard library, and the rapidly evolving design patterns we see in the community.</div><div class=""><br class=""></div><div class="">You challenged us on one part of this plan: some Foundation API just doesn’t “feel Swifty”, and a large part of the reason why is that it often does not have the same value type behavior as other Swift types. We took this feedback seriously, and I would like to share with you the start of an important journey for some of the most commonly used APIs on all of our platforms: adopting value semantics for key Foundation types.</div><div class=""><br class=""></div><div class="">We have been working on this for some time now, and the set of diffs that result from this change is large. At this point, I am going to focus effort on an overview of the high level goals and not the individual API of each new type. In order to focus on delivering something up to our quality standards, we are intentionally leaving some class types as-is until a future proposal. If you don’t see your favorite class on the list — don’t despair. We are going to iterate on this over time. I see this as the start of the process.</div><div class=""><br class=""></div><div class="">One process note: we are still trying to figure out the best way to integrate changes to API that ship as part of the operating system (which includes Foundation) into the swift-evolution review process. Swift-evolution is normally focused on changes to functionality in the compiler or standard library. In general, I don’t expect all new Foundation API introduced in the Darwin/Objective-C framework to go through the open source process. However, as we’ve brought up this topic here before, I felt it was important to bring this particular change to the swift-evolution list.</div><div class=""><br class=""></div><div class="">As always I welcome your feedback.</div><div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md</a></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">- Tony</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></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>