Hi Matthew, > On May 7, 2016, at 5:22 AM, Matthew Johnson <[email protected]> wrote: > > > > Sent from my iPad > > On May 7, 2016, at 5:03 AM, David Hart via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> Hi Tony, >> >> I'm very positive about the proposal but I have similar fears, even if less >> strong, to David Waite. I agree that the core libraries can be improved with >> time, but it's going to be difficult to rethink them profoundly. >> NSKeyedArchiver was an improvement, but a fairly mild one, to stay >> backwards-compatible. It's going to be difficult to introduce major changes, >> like the ones David Waite gave as example, post Swift 3. >> >> But on a more pragmatic level, I know there is not much we can do about it, >> with the current deadlines. All we can hope for is make corelibs-foundation >> as Swifty as possible by the time Swift 3 comes out. And I imagine that >> third party libraries will come to replace the aspects of it that feel too >> alien to Swift. >> >> Any thoughts? > > +1. I have similar concerns. The worst case would be if Foundation does not > eventually get the appropriate Swift-native rethinking and third party > libraries with the same functionality are developed for that reason. If that > happens the community will be split between those who favor various > libraries. That should not happen just because corelibs doesn't feel > Swift-native. > > It would be far better to see that happen as part of the evolution process so > we eventually end up with fully Swift-native types in Foundation itself. I > think a strong commitment to doing this over the next couple years would go a > long way towards addressing the concerns many of us have about this. >
I totally understand what you’re saying. I believe we’ve made that commitment, by virtue of placing Foundation (dispatch and XCTest too) into swift-corelibs and also by sending this proposal and the value types one to this list. We are trying to avoid exactly the split you are concerned about. There is always going to be new functionality in Foundation and other frameworks in the SDK that is tied to OS releases, which we simply cannot talk about here until those releases are made public. However, the rest of the Foundation team and I are always advocating for the best possible Swift API wherever and whenever we can. There is no doubt it will take time to make the many thousands of APIs that you use every day feel native and natural in Swift. I’ll beat the drum of iterative improvement again: the best way to get there from here is to make continuous adjustments and improvements from release to release. You will see the rethinking you are looking for over the course of that process. Thanks, - Tony >> >> David (Hart). >> >> On 07 May 2016, at 00:06, Tony Parker via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> Hi David, >>> >>>> On May 6, 2016, at 2:56 PM, David Waite <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> -1 On the group as-is. I do not believe all of these classes have the >>>> behavior that would be expected if ‘foundation’ were a from-scratch >>>> foundational library for Swift (as it exists on non Apple platforms). This >>>> will lock Swift into an evolutionary path for these types going forward. >>>> >>>> There is enough here that I will just pick one example to focus on - >>>> NSCoding/NSCoder, and elements I would suspect from such a from-scratch >>>> design >>>> >>>> - Coding would incorporate SecureCoding into its design (I did not see >>>> NSSecureCoding even on the list of protocols to get the prefix dropped) >>> >>> SecureCoding should be on the list actually. >>> >>>> - Archiver/Unarchiver would not exist; we would only have keyed versions >>>> - Coder would be a split in half to Coder and Decoder >>>> - Coder and Decoder would be protocols >>>> - The Coder protocol might have a single method, encode(value:Coding, >>>> forKey:String) >>>> - The Decoder protocol might single method, <T:Coding> decode(type:T.Type, >>>> forKey: String) -> T? >>>> - Compiler generation of a default Coding implementation >>>> >>>> And possibly more such as: >>>> - Add Coders limited to trees of objects vs graphs, to allow the >>>> Coder/Decoder protocols to be used for more intuitive JSON/XML >>>> representations >>>> - Custom/specific assignment operator for Decoder to capture desired type >>>> without requiring said type to be specified in decode(type:forKey:) calls >>>> >>>> -DW >>> >>> There’s no question that we can improve Coding for Swift. I have actually >>> explored this area quite a bit although I don’t have anything planned for >>> Swift 3 at this time. >>> >>> The general point is though, that we can do it by extending Foundation in >>> that direction over time. In fact, keyed archiving is the perfect example >>> of how we were able to do just that in the past in Objective-C. NSArchiver >>> already existed and served a particular purpose, so we extended the concept >>> into NSKeyedArchiver using the facilities available to us at the time. >>> >>> It’s not a goal to rewrite Foundation from scratch in Swift. All Swift apps >>> that are running out there today are in fact using a combination of Swift, >>> Objective-C, C, C++, various flavors of assembly, and more. The goal is to >>> present the existing API of Foundation in a way that fits in with the >>> language today while allowing us to iteratively improve it over time. >>> >>> - Tony >>> >>>> >>>>> On May 6, 2016, at 2:52 PM, Tony Parker via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> Thanks to all of you for your feedback on SE-0069 (Foundation Value >>>>> Types). I’m back again with more information on another part of our plan >>>>> to integrate Foundation API into Swift: dropping the NS prefix. >>>>> >>>>> When we originally proposed this as part of the API guidelines document >>>>> (SE-0023, >>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md >>>>> >>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md>), >>>>> we took a very broad approach to which classes would drop their prefix. >>>>> This time, we’ve narrowed the scope considerably, plus taken advantage of >>>>> the ability to nest types inside classes to further reduce the >>>>> possibility of introducing conflicting names. >>>>> >>>>> I’ve written up a draft of the proposal, which includes an extensive >>>>> section on motivation plus a list of changes. Please take a look and let >>>>> me know what you think. We’ll start a formal review period soon. >>>>> >>>>> https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/NNNN-drop-foundation-ns.md >>>>> >>>>> <https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/NNNN-drop-foundation-ns.md> >>>>> >>>>> Thanks again for your help, >>>>> - Tony >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
