On the one hand I like the idea (and particularly like the foundation types having meaningful `mutating` annotations, loosely speaking).
On the other hand I have two questions: 1. will the NS types actually remain visible/usable (on supported platforms, perhaps requiring a specific import to become visible)? 2. does this include — or are their separate plans for — exposing the backing reference type in some principled way? 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. I think this has come up before at some point, but if it did I didn’t follow it. My interest in (1.) is mostly b/c I suspect the answer to (2.) is “no”. Apologies if these are alrexdy-addressedd and I just missed it. > On Apr 22, 2016, at 12:18 PM, Tony Parker via swift-evolution > <[email protected]> wrote: > > Dear swift-evolution denizens, > > 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. > > 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. > > 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. > > 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. > > As always I welcome your feedback. > > https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md> > > Thanks, > - Tony > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
