[swift-evolution] Mutability for Foundation types in Swift

[Michael Buckley]

Having read the proposal a couple times now, I like it, but I have couple
if small questions, and I'm sure I'll have more in the next day or so. I'm
going to refer to NSData et. al. in the questions because that's the
example given in the proposal, but these questions should be more widely
applicable.

First, relating to customizing the behavior though a custom subclass to
NSData, I'm assuming that the as operator will box the instance of the
NSData subclass. That is, `MyData() as Data` will create a new instance of
MyData, a new instance of Data, and assign the MyData instance to the Data
instance's _box property.

If that's the case, why not make it more explicit that Data is wrapping
MyData and instead create an initializer for Data that takes the NSData
instance to wrap instead of using the as operator? It definitely matches
the use of the as operator from NSString to String, but that design
decision seems to predate a preference for initializers in type conversion,
and I'm wondering if there's a disadvantage to initializers or an advantage
to the as operator that I'm not seeing.

Second, let's say I have a MyMutableData class in Obj-C that's a subclass
of NSMutableData. I have an Objective-C method that returns an instance of
MyMutableData, and his function is called from Swift, and I do something
like `let foo = objCObj.objCMethod() as Data`. The foo instance is now
supposed to be immutable, but backed by a mutable Objective-C object. If I
then mutate the data in Objective-C, what happens?

If the answer to this is that the MyMutableData instance is copied in the
transfer from Objective-C to Swift so that mutations in Objective-C don't
affect the Swift instance, what about the case where I used `var foo`
instead of `let foo`? Does that mean that if I modify the data in
Objective-C that it won't get modified in Swift (and vice-versa)?


On Fri, Apr 22, 2016 at 10:18 AM, Tony Parker via swift-evolution <
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
>
> Thanks,
> - Tony
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> 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/0c62df4d/attachment.html>