> On Apr 22, 2016, at 1:53 PM, plx via swift-evolution > <[email protected]> wrote: > > 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)?
NSData will still exist and be available (as will NSMutableData) on all platforms including swift-corelibs versions; there are still some reasons to have reference semantics from time to time hence why the proposal did not take away any of them. > 2. does this include — or are their separate plans for — exposing the backing > reference type in some principled way? `as` cast will grant a reference type, but of course this has a potential of a copy semantic. A direct access to the underlying box that contains the object would be dangerous; in that references passed around for that container would be beyond the scope of data’s control (Tony might be able to speak on this a bit more than myself) The structure may later drop it’s reference to that object and construct a new version upon mutation etc. > > 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. let dataStructure = Data(bytes: someBytes, count: 5) let dataReference = dataStructure as NSData // this is a reference version of the structural container, but you should not count on the identity since the structure could mutate out and replace the backing storage. > > 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] <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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
