Dropping NS Prefix in Foundation


(Tony Parker) #1

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), 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

Thanks again for your help,
- Tony


(David Waite) #2

-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), 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

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


(Rod Brown) #3

I am definitely +1 to this proposal direction

I was in the crowd thinking "don't drop the NS on types that should be value types" but I think you make fair points that there can be planned optimizations in the future, and we should focus on getting a good set of naming rules in place. You make decent rules about how to migrate going forward.

I'm definitely in favor of the hoisted types, enum updates etc.

I found it interesting that NSOrderedSet has been left out of this proposal. Is there any reason for this? I only thought about it in regard to the previous mention a few days ago heh.

Thanks Tony for pushing this forward.

- Rod

···

On 7 May 2016, at 6:52 AM, 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), 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

Thanks again for your help,
- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Haravikk) #4

I have mixed feelings about this; while I agree that prefixing names isn’t a good fit for Swift, at the same time that’s kind of the appeal of it. Assuming that Foundation will eventually be replaced by a more Swift-like alternative, or will be incrementally reworked, I think it makes sense for it to feel a little weird to use as it is right now.

The NS prefix makes it clear that this is something different, something not originally designed with Swift in mind, and in a way that’s a good thing. I know in my own case it makes me instinctively shy away from it, and actually encourages me to wrap NS constructs in something more Swift-like for convenience.

···

On 6 May 2016, at 21:52, 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), 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

Thanks again for your help,
- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Parker) #5

Hi David,

-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:56 PM, David Waite <david@alkaline-solutions.com> wrote:

On May 6, 2016, at 2:52 PM, Tony Parker via swift-evolution <swift-evolution@swift.org <mailto: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), 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

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


(David Hart) #6

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?

David (Hart).

···

On 07 May 2016, at 00:06, Tony Parker via swift-evolution <swift-evolution@swift.org> wrote:

Hi David,

On May 6, 2016, at 2:56 PM, David Waite <david@alkaline-solutions.com> 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 <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), 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

Thanks again for your help,
- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charles Srstka) #7

The trouble with (NS)Coding is that due to the legacy cruft, you have to consider the possibility that the coder sent to your -initWithCoder: and similar methods could be insecure coders and/or non-keyed coders, and either support each branch (making your method three times as long as it needs to be), or add code to error out if you get one of the legacy coder types.

A brand new coding mechanism, built from scratch, would be kind of refreshing in that regard.

Charles

···

On May 6, 2016, at 5:06 PM, Tony Parker via swift-evolution <swift-evolution@swift.org> wrote:

Hi David,

On May 6, 2016, at 2:56 PM, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> 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


(Patrick Smith) #8

Should deprecated / unsafe classes be renamed with some sort of prefix, such as UnsafeCoder? Or leave them as original, NSCoder? Just to highlight alternatives should be used instead.

···

On 7 May 2016, at 8:06 AM, Tony Parker via swift-evolution <swift-evolution@swift.org> wrote:

Hi David,

On May 6, 2016, at 2:56 PM, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> 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 <swift-evolution@swift.org <mailto: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), 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

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Waite) #9

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.

Perhaps my concern is a higher level - I don’t understand where Foundation is envisioned going.

-DW

···

From my perspective, Foundation is highly coupled to Apple platforms and Objective-C on one side, and part of the Swift standard library on the other. Perhaps long-term Foundation should be split into two new things - a core library for cross-platform swift development, and the infrastructure for Objective-C interoperability on apple platforms only.


(Sean Heber) #10

If I am coming to Swift as a new user (possibly as a first language, even) without any prior Objective-C experience and very little knowledge of the long history of Foundation, the NS prefix, etc, this is going to feel worse than a little out of place - it will feel downright wrong, broken, and confusing to see these weird NS prefixes on some seemingly “standard” classes and not on others.

I’m +1 for removing the NS and evolving forward from there - let’s not create a confusing tangle of old and new that is navigable only by those with knowledge of the esoteric.

l8r
Sean

···

On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

I have mixed feelings about this; while I agree that prefixing names isn’t a good fit for Swift, at the same time that’s kind of the appeal of it. Assuming that Foundation will eventually be replaced by a more Swift-like alternative, or will be incrementally reworked, I think it makes sense for it to feel a little weird to use as it is right now.

The NS prefix makes it clear that this is something different, something not originally designed with Swift in mind, and in a way that’s a good thing. I know in my own case it makes me instinctively shy away from it, and actually encourages me to wrap NS constructs in something more Swift-like for convenience.

On 6 May 2016, at 21:52, 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), 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

Thanks again for your help,
- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Zachary Waldowski) #11

This is exactly the way I see it, too. Many people are coming to Swift
and immediately decrying the language because it doesn't have built-in
support for regex, date parsing, collections beyond the built-in 3,
etc., when it in fact has a rich tapestry of things from Foundation.

While I agree with many of the points made in the thread, I think we're
missing the forest for the trees. Foundation is the best at many of the
things it does on any platform. This is in spite of many of the points
made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
It *does* have crufty edges.

Foundation not having a super-Swifty API is a solvable problem over
time, of which this is a first step down that road. Revamping the
Foundation API in the Swift 3 timeframe is not a solvable problem.

Cheers
Zach Waldowski
zach@waldowski.me

···

On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:

If I am coming to Swift as a new user (possibly as a first language,
even) without any prior Objective-C experience and very little knowledge
of the long history of Foundation, the NS prefix, etc, this is going to
feel worse than a little out of place - it will feel downright wrong,
broken, and confusing to see these weird NS prefixes on some seemingly
“standard” classes and not on others.

I’m +1 for removing the NS and evolving forward from there - let’s not
create a confusing tangle of old and new that is navigable only by those
with knowledge of the esoteric.

l8r
Sean

> On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
>
> I have mixed feelings about this; while I agree that prefixing names isn’t a good fit for Swift, at the same time that’s kind of the appeal of it. Assuming that Foundation will eventually be replaced by a more Swift-like alternative, or will be incrementally reworked, I think it makes sense for it to feel a little weird to use as it is right now.
>
> The NS prefix makes it clear that this is something different, something not originally designed with Swift in mind, and in a way that’s a good thing. I know in my own case it makes me instinctively shy away from it, and actually encourages me to wrap NS constructs in something more Swift-like for convenience.
>
>> On 6 May 2016, at 21:52, 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), 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
>>
>> Thanks again for your help,
>> - Tony
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #12

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.

···

Sent from my iPad

On May 7, 2016, at 5:03 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

David (Hart).

On 07 May 2016, at 00:06, Tony Parker via swift-evolution <swift-evolution@swift.org> wrote:

Hi David,

On May 6, 2016, at 2:56 PM, David Waite <david@alkaline-solutions.com> 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 <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), 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

Thanks again for your help,
- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Parker) #13

Hi David,

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

···

On May 7, 2016, at 3:03 AM, David Hart <david@hartbit.com> wrote:

David (Hart).

On 07 May 2016, at 00:06, Tony Parker via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi David,

On May 6, 2016, at 2:56 PM, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> 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 <swift-evolution@swift.org <mailto: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), 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

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Parker) #14

Hi Matthew,

Sent from my iPad

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

···

On May 7, 2016, at 5:22 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On May 7, 2016, at 5:03 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

David (Hart).

On 07 May 2016, at 00:06, Tony Parker via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi David,

On May 6, 2016, at 2:56 PM, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> 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 <swift-evolution@swift.org <mailto: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), 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

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #15

Hi Matthew,

Sent from my iPad

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.

Thank you for the reply and openness Tony.

I think our concern stems from a couple of places. Possibly most important is that there has been significant effort to introduce as many breaking changes into Swift 3 as possible and a general sense that there will be a pretty high bar for breaking changes in the future. Many of changes we hope to see in a Swift native rethink / redesign will be significant breaking changes if they are made to the existing types. We are focused on the *design* of the APIs, not just the naming of specific methods. Their Cocoa and Objective-C origin will be quite apparent despite the renaming which will make them somewhat more comfortable in Swift. Is there really appetite for making breaking changes on the scale necessary for a Swift native design in Swift 4, 5, 6, etc (assuming it takes several iterations to complete)?

Secondarily, as long as the design of Foundation is constrained by the need to be usable from Objective-C this constraint is likely to influence the Swift interface in some way. I imagine this constraint will be around for a while quite a while. That could slow the the arrival of designs that are true to the spirit of Swift.

I understand the need for pragmatism and appreciate the desire to make our experience in Swift 3 be as pleasant as possible. At the same time, I fear that taking the approach of evolving Foundation as the long term strategy will lead to a suboptimal result and / or the split in the community I mentioned. There are several factors that could contribute to this:

1. Evolving existing API rather than designing from scratch will lead to different results. Designing from scratch will likely lead to a better result from a "pure Swift" perspective as there will not be any legacy baggage.

2. If the underlying implementation is going to need to be available in Objective-C as well for quite a while it will probably delay highly desired changes, thus leaving a window where the community may split.

3. We may reach a place in 3 years where everyone acknowledges the library API are not close to what we would design if we could do it over, but the will for breaking changes of the scale necessary just isn't there.

Can you elaborate on why Foundation must be the long term solution? I wonder if it wouldn't be better if the long term solution was a new, Swift native module. This would allow us to make Foundation more comfortable in the near term while avoiding breaking changes when Swift native designs are introduced. It would also encourage community members who wish to design something more Swifty to work on that as part of the evolution process or as a precursor to evolution (along the lines of Boost).

If Foundation must be the long term solution it looks to me like these are our options:

1. Keep the NS prefixes until types are redesigned.
2. Face significant breaking changes in the future when Swift native designs are introduced
3. Live with designs in Foundation that don't feel Swift native, likely leading to an alternative from the community that feels more Swifty.

If these are the options we have available my preference is for #1. However, maybe we can achieve the benefits of this approach while simultaneously enabling a more comfortable Foundation experience in the near term simply by deciding to treat Foundation as a bridge to a future that will eventually move beyond it.

Matthew

···

Sent from my iPad

On May 7, 2016, at 11:14 AM, Tony Parker <anthony.parker@apple.com> wrote:

On May 7, 2016, at 5:22 AM, Matthew Johnson <matthew@anandabits.com> wrote:

On May 7, 2016, at 5:03 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Thanks,
- Tony

David (Hart).

On 07 May 2016, at 00:06, Tony Parker via swift-evolution <swift-evolution@swift.org> wrote:

Hi David,

On May 6, 2016, at 2:56 PM, David Waite <david@alkaline-solutions.com> 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 <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), 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

Thanks again for your help,
- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Josh Parmenter) #16

David has articulated what I couldn't quite put my finger on, and I agree.
This also comes around to something I probably missed elsewhere in the discussion- but is the proposal to make NS classes just look like thus don't have NS in Swift? Or is it to write Swift versions of those classes that duplicate the functionality of those classes in Swift (for instance, giving String the full interface of NSString without actually having it call into NSString obj-c code?).
I tried glancing through the discussion and couldn't really find an answer to this (though I did it quickly, so my apologies if this is an obvious question that has already been answered).
Best
Josh

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.

Perhaps my concern is a higher level - I don't understand where Foundation is envisioned going.

From my perspective, Foundation is highly coupled to Apple platforms and Objective-C on one side, and part of the Swift standard library on the other. Perhaps long-term Foundation should be split into two new things - a core library for cross-platform swift development, and the infrastructure for Objective-C interoperability on apple platforms only.

-DW

···

Sent from my iPhone
On May 8, 2016, at 00:41, David Waite via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Austin Zheng) #17

In addition to the points that have been raised, it's my opinion that some
of the stuff in Foundation should really be implemented in the stdlib in
the future (for example, collections that weakly reference their items, and
a native binary data blob type). The fact that the delineation between what
goes in the stdlib and what goes in Foundation is the result of historical
happenstance does not really sit well with me. I think that Foundation's
evolution should be done with this in mind, such that in the future certain
Foundation classes might be implemented as stubs built on top of native
data structures, with additional functionality for legacy compatibility
(sort of like how String works today).

Best,
Austin

···

On Mon, May 9, 2016 at 9:03 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

Sent from my iPad

> On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution < > swift-evolution@swift.org> wrote:
>
> This is exactly the way I see it, too. Many people are coming to Swift
> and immediately decrying the language because it doesn't have built-in
> support for regex, date parsing, collections beyond the built-in 3,
> etc., when it in fact has a rich tapestry of things from Foundation.
>
> While I agree with many of the points made in the thread, I think we're
> missing the forest for the trees. Foundation is the best at many of the
> things it does on any platform. This is in spite of many of the points
> made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
> It *does* have crufty edges.
>
> Foundation not having a super-Swifty API is a solvable problem over
> time, of which this is a first step down that road. Revamping the
> Foundation API in the Swift 3 timeframe is not a solvable problem.

I agree with everything you say here. My only concern is trying to ensure
we don't take steps today that will make it difficult to implement the best
design down the road.

>
> Cheers
> Zach Waldowski
> zach@waldowski.me
>
>> On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:
>> If I am coming to Swift as a new user (possibly as a first language,
>> even) without any prior Objective-C experience and very little knowledge
>> of the long history of Foundation, the NS prefix, etc, this is going to
>> feel worse than a little out of place - it will feel downright wrong,
>> broken, and confusing to see these weird NS prefixes on some seemingly
>> “standard” classes and not on others.
>>
>> I’m +1 for removing the NS and evolving forward from there - let’s not
>> create a confusing tangle of old and new that is navigable only by those
>> with knowledge of the esoteric.
>>
>> l8r
>> Sean
>>
>>
>>> On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote:
>>>
>>> I have mixed feelings about this; while I agree that prefixing names
isn’t a good fit for Swift, at the same time that’s kind of the appeal of
it. Assuming that Foundation will eventually be replaced by a more
Swift-like alternative, or will be incrementally reworked, I think it makes
sense for it to feel a little weird to use as it is right now.
>>>
>>> The NS prefix makes it clear that this is something different,
something not originally designed with Swift in mind, and in a way that’s a
good thing. I know in my own case it makes me instinctively shy away from
it, and actually encourages me to wrap NS constructs in something more
Swift-like for convenience.
>>>
>>>> On 6 May 2016, at 21:52, 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),
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
>>>>
>>>> Thanks again for your help,
>>>> - Tony
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Parker) #18

Hi Matthew (and others),

Sent from my iPad

This is exactly the way I see it, too. Many people are coming to Swift
and immediately decrying the language because it doesn't have built-in
support for regex, date parsing, collections beyond the built-in 3,
etc., when it in fact has a rich tapestry of things from Foundation.

While I agree with many of the points made in the thread, I think we're
missing the forest for the trees. Foundation is the best at many of the
things it does on any platform. This is in spite of many of the points
made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
It *does* have crufty edges.

Foundation not having a super-Swifty API is a solvable problem over
time, of which this is a first step down that road. Revamping the
Foundation API in the Swift 3 timeframe is not a solvable problem.

I agree with everything you say here. My only concern is trying to ensure we don't take steps today that will make it difficult to implement the best design down the road.

It’s true that Foundation is the foundation of the Objective-C stack. However, while some see this as a weakness, I see it as a great opportunity. The role of this library puts it in a unique spot as a leverage point: low enough level to be used in nearly all applications on all platforms, but high enough level to establish API and patterns that you see across the SDK.

The idea of leaving existing API behind somehow by keeping the prefix means that the leverage would be gone. With all existing API in terms of those existing types, any new types are effectively unused in all API above Foundation. We would need to introduce conversion methods to move between the two types (if that is even possible).

If, instead, we evolve the existing API to be better for Swift, then we benefit the entire stack without having a boil-the-ocean type of adoption problem. Therefore, we have already made the decision that we are not going to invent an entirely new set of a fundamental types but to instead iteratively improve the API of the ones we have.

- Tony

···

On May 9, 2016, at 9:03 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution <swift-evolution@swift.org> wrote:

Cheers
Zach Waldowski
zach@waldowski.me

On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:
If I am coming to Swift as a new user (possibly as a first language,
even) without any prior Objective-C experience and very little knowledge
of the long history of Foundation, the NS prefix, etc, this is going to
feel worse than a little out of place - it will feel downright wrong,
broken, and confusing to see these weird NS prefixes on some seemingly
“standard” classes and not on others.

I’m +1 for removing the NS and evolving forward from there - let’s not
create a confusing tangle of old and new that is navigable only by those
with knowledge of the esoteric.

l8r
Sean

On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

I have mixed feelings about this; while I agree that prefixing names isn’t a good fit for Swift, at the same time that’s kind of the appeal of it. Assuming that Foundation will eventually be replaced by a more Swift-like alternative, or will be incrementally reworked, I think it makes sense for it to feel a little weird to use as it is right now.

The NS prefix makes it clear that this is something different, something not originally designed with Swift in mind, and in a way that’s a good thing. I know in my own case it makes me instinctively shy away from it, and actually encourages me to wrap NS constructs in something more Swift-like for convenience.

On 6 May 2016, at 21:52, 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), 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

Thanks again for your help,
- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #19

This is exactly the way I see it, too. Many people are coming to Swift
and immediately decrying the language because it doesn't have built-in
support for regex, date parsing, collections beyond the built-in 3,
etc., when it in fact has a rich tapestry of things from Foundation.

While I agree with many of the points made in the thread, I think we're
missing the forest for the trees. Foundation is the best at many of the
things it does on any platform. This is in spite of many of the points
made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
It *does* have crufty edges.

Foundation not having a super-Swifty API is a solvable problem over
time, of which this is a first step down that road. Revamping the
Foundation API in the Swift 3 timeframe is not a solvable problem.

I agree with everything you say here. My only concern is trying to ensure we don't take steps today that will make it difficult to implement the best design down the road.

···

Sent from my iPad

On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution <swift-evolution@swift.org> wrote:

Cheers
  Zach Waldowski
  zach@waldowski.me

On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:
If I am coming to Swift as a new user (possibly as a first language,
even) without any prior Objective-C experience and very little knowledge
of the long history of Foundation, the NS prefix, etc, this is going to
feel worse than a little out of place - it will feel downright wrong,
broken, and confusing to see these weird NS prefixes on some seemingly
“standard” classes and not on others.

I’m +1 for removing the NS and evolving forward from there - let’s not
create a confusing tangle of old and new that is navigable only by those
with knowledge of the esoteric.

l8r
Sean

On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

I have mixed feelings about this; while I agree that prefixing names isn’t a good fit for Swift, at the same time that’s kind of the appeal of it. Assuming that Foundation will eventually be replaced by a more Swift-like alternative, or will be incrementally reworked, I think it makes sense for it to feel a little weird to use as it is right now.

The NS prefix makes it clear that this is something different, something not originally designed with Swift in mind, and in a way that’s a good thing. I know in my own case it makes me instinctively shy away from it, and actually encourages me to wrap NS constructs in something more Swift-like for convenience.

On 6 May 2016, at 21:52, 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), 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

Thanks again for your help,
- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #20

Hi Matthew (and others),

Sent from my iPad

This is exactly the way I see it, too. Many people are coming to Swift
and immediately decrying the language because it doesn't have built-in
support for regex, date parsing, collections beyond the built-in 3,
etc., when it in fact has a rich tapestry of things from Foundation.

While I agree with many of the points made in the thread, I think we're
missing the forest for the trees. Foundation is the best at many of the
things it does on any platform. This is in spite of many of the points
made: it *has* an Objective-C API. It *is* coupled to Apple platforms.
It *does* have crufty edges.

Foundation not having a super-Swifty API is a solvable problem over
time, of which this is a first step down that road. Revamping the
Foundation API in the Swift 3 timeframe is not a solvable problem.

I agree with everything you say here. My only concern is trying to ensure we don't take steps today that will make it difficult to implement the best design down the road.

It’s true that Foundation is the foundation of the Objective-C stack. However, while some see this as a weakness, I see it as a great opportunity. The role of this library puts it in a unique spot as a leverage point: low enough level to be used in nearly all applications on all platforms, but high enough level to establish API and patterns that you see across the SDK.

The idea of leaving existing API behind somehow by keeping the prefix means that the leverage would be gone. With all existing API in terms of those existing types, any new types are effectively unused in all API above Foundation. We would need to introduce conversion methods to move between the two types (if that is even possible).

If, instead, we evolve the existing API to be better for Swift, then we benefit the entire stack without having a boil-the-ocean type of adoption problem. Therefore, we have already made the decision that we are not going to invent an entirely new set of a fundamental types but to instead iteratively improve the API of the ones we have.

I understand where you’re coming from and appreciate the reasons for the decision. As a developer working on Apple platforms I will receive immediate benefit from this direction in the near term.

At the same time I do think it is a path that could lead to a less cohesive community. We may see alternative, Swift-native libraries emerge especially from those using Swift on non-Apple platforms (server side, etc). I hope the “Swiftification of Foundation” is able to move quickly enough and feel idiomatic enough to prevent that from happening. I’m sure you’ve given this plenty of thought already internally.

-Matthew

···

On May 9, 2016, at 12:26 PM, Tony Parker <anthony.parker@apple.com> wrote:

On May 9, 2016, at 9:03 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

- Tony

Cheers
Zach Waldowski
zach@waldowski.me <mailto:zach@waldowski.me>

On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:
If I am coming to Swift as a new user (possibly as a first language,
even) without any prior Objective-C experience and very little knowledge
of the long history of Foundation, the NS prefix, etc, this is going to
feel worse than a little out of place - it will feel downright wrong,
broken, and confusing to see these weird NS prefixes on some seemingly
“standard” classes and not on others.

I’m +1 for removing the NS and evolving forward from there - let’s not
create a confusing tangle of old and new that is navigable only by those
with knowledge of the esoteric.

l8r
Sean

On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I have mixed feelings about this; while I agree that prefixing names isn’t a good fit for Swift, at the same time that’s kind of the appeal of it. Assuming that Foundation will eventually be replaced by a more Swift-like alternative, or will be incrementally reworked, I think it makes sense for it to feel a little weird to use as it is right now.

The NS prefix makes it clear that this is something different, something not originally designed with Swift in mind, and in a way that’s a good thing. I know in my own case it makes me instinctively shy away from it, and actually encourages me to wrap NS constructs in something more Swift-like for convenience.

On 6 May 2016, at 21:52, Tony Parker via swift-evolution <swift-evolution@swift.org <mailto: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), 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

Thanks again for your help,
- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution