Hi David, > On May 7, 2016, at 3:03 AM, David Hart <[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? > I’m confident we can still introduce major changes if and when we need to. The value types stuff is a pretty major change, and we are able to find a way to introduce it in the 3rd major version of Swift instead of having to do it in the 1st. I see future improvements the same way. We may not even know right now what the most important improvement to Foundation is to make it fit in with Swift 4 or Swift 5. That is why I’m focusing on improving what we have so that we can iterate and improve alongside the language itself. - 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] https://lists.swift.org/mailman/listinfo/swift-evolution
