Hi Nate, > On Apr 22, 2016, at 11:55 AM, Nate Cook <[email protected]> wrote: > > This looks amazing—really looking forward to seeing the progression here! > > I do have a question about how copy-on-write is handled for larger data types > like Data (née NSData). The standard library types that can use bridged > storage use immutable classes until there's a mutation, at which point the > contents are copied into native storage. From then on (as long as the native > storage is still uniquely referenced) the contents can be mutated in place > without any copying. > > With the proposed value semantics around an NSData instance, how do you > handle that in-place mutation? When bridging from Objective-C to Swift, it > sounds like you'll call copy() on an NSData instance. Does NSMutableData > perform the role of the native storage when mutating? If so, is another copy > needed when bridging a Data instance backed by NSMutableData back to NSData? > > The proposal says: "For reference-holding types like Data, we simply pass our > interior NSData pointer back to Objective-C. The underlying data is not > copied at bridging time." If the Data instance is backed by NSMutableData, > can we still successfully check for uniqueness once we pass it back to > Objective-C? > > Thanks! > Nate >
In reality, the stored reference object is a Swift class with Swift-native ref counting that implements the methods of the Objective-C NSData “protocol” (the interface described by @interface NSData) by holding a “real” NSMutableData ivar and forwarding messages to it. This technique is actually already in use in the standard library. Starts around here: https://github.com/apple/swift/blob/master/stdlib/public/core/Runtime.swift.gyb#L497 and then look here: https://github.com/apple/swift/blob/e67acdb70d8887507747d0ed14898306f07a74f4/stdlib/public/stubs/SwiftNativeNSXXXBase.mm.gyb#L59 and finally here: https://github.com/apple/swift/blob/4fd8418ba724963e1414e4d720a05bb9cc5fb77a/stdlib/public/core/SwiftNativeNSArray.swift#L40 This means that if an Objective-C client calls retain on this object (which is a _SwiftNativeNSData), it actually calls swift_retain, which mutates the Swift ref count. This means that a call to _isUniquelyReferencedNonObjC from Swift actually still works on this class type. - Tony > >> On Apr 22, 2016, at 12:18 PM, Tony Parker via swift-evolution >> <[email protected] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
