One comment: "In the most common case where a developer does not provide a custom reference type, then the backing store is our existing NSData and NSMutableData implementations. This consolidates logic into one place and provides cheap bridging in many cases (see Bridging for more information).”
Would it not be more efficient to bridge to the C-based CFData and CFMutableData implementations instead, to avoid the object overhead? Charles > On Apr 22, 2016, at 12:18 PM, Tony Parker via swift-evolution > <swift-evolution@swift.org> 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 > > Thanks, > - Tony > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
