-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) - 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 > On May 6, 2016, at 2:52 PM, Tony Parker via swift-evolution > <swift-evolution@swift.org> 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 > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
