[swift-evolution] Mutability for Foundation types in Swift

[Tony Parker]

Hi Nate,

> On Apr 22, 2016, at 11:55 AM, Nate Cook <natecook at gmail.com> 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 <swift-evolution at swift.org <mailto:swift-evolution at 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 <https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md>
>> 
>> Thanks,
>> - Tony
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160422/7677f252/attachment.html>