[swift-evolution] Dropping NS Prefix in Foundation

[David Waite]

-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 at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160506/f100b64c/attachment.html>