Hi David, > On Apr 22, 2016, at 12:13 PM, David Waite <[email protected]> > wrote: > > Amazing, I am really looking forward to this feature! > > Comments: > > - For Locale and Calendar, one possible Swift layout would be to synthesize a > protocol and to use that to represent bridged API. You could then bridge > inbound to either the immutable value type or the dynamic class-based type. > On the swift side, these are constructed as two distinct types.
That’s an interesting approach, I’ll consider that for these. > > - For any of these types, are there improvements (similar to String) which > would be worth making before exposing ’the’ Swift type and API? The ones I’m > specifically worried about are Date and URL, since I’ve seen so many standard > language time and networking API show their age over time. > > -DW We’re absolutely going to be making Swift-specific improvements to many of these types. I think the resulting API is better in many ways. For example, on URL the main improvement is that the resource values dictionary is now struct type with a lot of strongly-typed properties. It’s still got a lot of optionals because of the way that the underlying fetch works, but it’s better. Date gains mutating methods along with support for operators like += and < >. One of the guiding principles of our effort was evolution over revolution. Foundation is obviously used in tons and tons of API. We want to maintain conceptual compatibility with the entire OS X / iOS / watchOS / tvOS SDK when it is imported into Swift. Hopefully this also means that converting from reference to value types in your own uses of these API does not require a complete rethink of how you use them, but still provide the benefits outlined in the proposal. We’ll continue to iterate and improve over time. Thanks, - Tony > >> On Apr 22, 2016, at 11:18 AM, 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
