Dropping NS Prefix in Foundation

Evolution Discussion
21

Foundation is indeed tightly coupled with the Apple ecosystem; however with the movement to open source, I think we are approaching a fork in the
road regarding this discussion. Like David articulated, Foundation either will need to her decoupled from its Apple historical roots or a parallel non-Apple Foundation will need to be developed. We all know how difficult and painful it is to maintain two different code sets that do mostly the same thing. My humble recommendation is that we start looking at decoupling foundation from its roots and a good first step would be to remove the NS- prefix. This change would do many positive things, including alerting developers that change is coming.

A long-term concern that I have is that if you do not begin the enormous task of at least beginning to remove Apple-centric dependencies, then sometime down the road someone outside the Apple environment will fork Swift and take it in ways out of our control.

In short, I am in favor of at least beginning the move toward removing NS- from Foundation.

···

On May 8, 2016, at 11:16 AM, Josh Parmenter via swift-evolution <swift-evolution@swift.org> wrote:

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

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:

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
_______________________________________________
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

22

But if the NS- prefix is removed now, then it will make it more painful to have breaking changes down the road. I’d prefer to see breaking changes happen and the introduction of new completely modern APIs. Even just protocols that the NS- Foundation can implement.

Say for example, a FileReferenceProtocol and a URLProtocol, where NSURL could conform to both, but a modern implementation could have two separate concrete struct types. Maybe that’s not feasible.

It’s just a shame to say ‘goodbye Objective-C, hello Swift clean slate’, and then bring Foundation along for the ride as a core part for writing new modern applications.

It would be great in my mind to have a plan to transition to a modern ‘Foundation 2.0’. Say made using Swift 4.0 and its possible concurrency operators. I think that would be the time to drop the NS- prefixes.

···

On 9 May 2016, at 3:09 AM, Michael Sheaver via swift-evolution <swift-evolution@swift.org> wrote:

Foundation is indeed tightly coupled with the Apple ecosystem; however with the movement to open source, I think we are approaching a fork in the
road regarding this discussion. Like David articulated, Foundation either will need to her decoupled from its Apple historical roots or a parallel non-Apple Foundation will need to be developed. We all know how difficult and painful it is to maintain two different code sets that do mostly the same thing. My humble recommendation is that we start looking at decoupling foundation from its roots and a good first step would be to remove the NS- prefix. This change would do many positive things, including alerting developers that change is coming.

A long-term concern that I have is that if you do not begin the enormous task of at least beginning to remove Apple-centric dependencies, then sometime down the road someone outside the Apple environment will fork Swift and take it in ways out of our control.

In short, I am in favor of at least beginning the move toward removing NS- from Foundation.

On May 8, 2016, at 11:16 AM, Josh Parmenter via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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

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><mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org><mailto: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

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

23

I'm +1 for this proposal. It is, IMO, a sensible way to evolve the current
situation to provide for a nicer experience.

As far as I can tell, arguments against the proposal argue for the
elimination of Foundation and a totally new set of Swift-native facilities,
which unless I'm mistaken is not at all on the roadmap. I just cannot agree
that a superior alternative to this proposal is "wait for Swift 4." Why
stop there? I hear Swift 9 is going to be pretty great...

···

On Sun, May 8, 2016 at 11:24 PM Patrick Smith via swift-evolution < swift-evolution@swift.org> wrote:

But if the NS- prefix is removed now, then it will make it more painful to
have breaking changes down the road. I’d prefer to see breaking changes
happen and the introduction of new completely modern APIs. Even just
protocols that the NS- Foundation can implement.

Say for example, a FileReferenceProtocol and a URLProtocol, where NSURL
could conform to both, but a modern implementation could have two separate
concrete struct types. Maybe that’s not feasible.

It’s just a shame to say ‘goodbye Objective-C, hello Swift clean slate’,
and then bring Foundation along for the ride as a core part for writing new
modern applications.

It would be great in my mind to have a plan to transition to a modern
‘Foundation 2.0’. Say made using Swift 4.0 and its possible concurrency
operators. I think that would be the time to drop the NS- prefixes.

On 9 May 2016, at 3:09 AM, Michael Sheaver via swift-evolution < > swift-evolution@swift.org> wrote:

Foundation is indeed tightly coupled with the Apple ecosystem; however
with the movement to open source, I think we are approaching a fork in the
road regarding this discussion. Like David articulated, Foundation either
will need to her decoupled from its Apple historical roots or a parallel
non-Apple Foundation will need to be developed. We all know how difficult
and painful it is to maintain two different code sets that do mostly the
same thing. My humble recommendation is that we start looking at decoupling
foundation from its roots and a good first step would be to remove the NS-
prefix. This change would do many positive things, including alerting
developers that change is coming.

A long-term concern that I have is that if you do not begin the enormous
task of at least beginning to remove Apple-centric dependencies, then
sometime down the road someone outside the Apple environment will fork
Swift and take it in ways out of our control.

In short, I am in favor of at least beginning the move toward removing NS-
from Foundation.

On May 8, 2016, at 11:16 AM, Josh Parmenter via swift-evolution < > swift-evolution@swift.org> wrote:

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

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 > <swift-evolution@swift.org>>> wrote:

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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org
<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

24

My point isn’t about what Swift 4 could be, but a timeline for something new to be made. Swift 3 is almost here. Personally I think Foundation, while venerable for its time, is a poor fit for the new world of Swift. Anyway, I’ll let the others speak as they had valid arguments.

···

On 9 May 2016, at 3:40 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

I'm +1 for this proposal. It is, IMO, a sensible way to evolve the current situation to provide for a nicer experience.

As far as I can tell, arguments against the proposal argue for the elimination of Foundation and a totally new set of Swift-native facilities, which unless I'm mistaken is not at all on the roadmap. I just cannot agree that a superior alternative to this proposal is "wait for Swift 4." Why stop there? I hear Swift 9 is going to be pretty great...
On Sun, May 8, 2016 at 11:24 PM Patrick Smith via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
But if the NS- prefix is removed now, then it will make it more painful to have breaking changes down the road. I’d prefer to see breaking changes happen and the introduction of new completely modern APIs. Even just protocols that the NS- Foundation can implement.

Say for example, a FileReferenceProtocol and a URLProtocol, where NSURL could conform to both, but a modern implementation could have two separate concrete struct types. Maybe that’s not feasible.

It’s just a shame to say ‘goodbye Objective-C, hello Swift clean slate’, and then bring Foundation along for the ride as a core part for writing new modern applications.

It would be great in my mind to have a plan to transition to a modern ‘Foundation 2.0’. Say made using Swift 4.0 and its possible concurrency operators. I think that would be the time to drop the NS- prefixes.

On 9 May 2016, at 3:09 AM, Michael Sheaver via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Foundation is indeed tightly coupled with the Apple ecosystem; however with the movement to open source, I think we are approaching a fork in the
road regarding this discussion. Like David articulated, Foundation either will need to her decoupled from its Apple historical roots or a parallel non-Apple Foundation will need to be developed. We all know how difficult and painful it is to maintain two different code sets that do mostly the same thing. My humble recommendation is that we start looking at decoupling foundation from its roots and a good first step would be to remove the NS- prefix. This change would do many positive things, including alerting developers that change is coming.

A long-term concern that I have is that if you do not begin the enormous task of at least beginning to remove Apple-centric dependencies, then sometime down the road someone outside the Apple environment will fork Swift and take it in ways out of our control.

In short, I am in favor of at least beginning the move toward removing NS- from Foundation.

On May 8, 2016, at 11:16 AM, Josh Parmenter via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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

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><mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org><mailto: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

25

My point isn’t about what Swift 4 could be, but a timeline for something
new to be made. Swift 3 is almost here. Personally I think Foundation,
while venerable for its time, is a poor fit for the new world of Swift.
Anyway, I’ll let the others speak as they had valid arguments.

I don't disagree with you that Foundation is venerable and a little out of
place. I just think some future replacement for Foundation is entirely
orthogonal to proposals about present-day improvements that improve it.

And please don't take my comments to be calling you out specifically; you
happened to be the most recent person to mention a future version of Swift,
but in earlier comments there are mentions of Swift 5 or Swift 6 being the
point at which language facilities will permit a pure Swift replacement for
Foundation. Let's say one of those Swift 6 features then slips to Swift 7,
after which we finally start work on NewFoundation, to be shipped with
Swift 8. Now the year is 2021 and we've already colonized Mars...

···

On Mon, May 9, 2016 at 2:47 AM, Patrick Smith <pgwsmith@gmail.com> wrote:

On 9 May 2016, at 3:40 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

I'm +1 for this proposal. It is, IMO, a sensible way to evolve the current
situation to provide for a nicer experience.

As far as I can tell, arguments against the proposal argue for the
elimination of Foundation and a totally new set of Swift-native facilities,
which unless I'm mistaken is not at all on the roadmap. I just cannot agree
that a superior alternative to this proposal is "wait for Swift 4." Why
stop there? I hear Swift 9 is going to be pretty great...
On Sun, May 8, 2016 at 11:24 PM Patrick Smith via swift-evolution < > swift-evolution@swift.org> wrote:

But if the NS- prefix is removed now, then it will make it more painful
to have breaking changes down the road. I’d prefer to see breaking changes
happen and the introduction of new completely modern APIs. Even just
protocols that the NS- Foundation can implement.

Say for example, a FileReferenceProtocol and a URLProtocol, where NSURL
could conform to both, but a modern implementation could have two separate
concrete struct types. Maybe that’s not feasible.

It’s just a shame to say ‘goodbye Objective-C, hello Swift clean slate’,
and then bring Foundation along for the ride as a core part for writing new
modern applications.

It would be great in my mind to have a plan to transition to a modern
‘Foundation 2.0’. Say made using Swift 4.0 and its possible concurrency
operators. I think that would be the time to drop the NS- prefixes.

On 9 May 2016, at 3:09 AM, Michael Sheaver via swift-evolution < >> swift-evolution@swift.org> wrote:

Foundation is indeed tightly coupled with the Apple ecosystem; however
with the movement to open source, I think we are approaching a fork in the
road regarding this discussion. Like David articulated, Foundation either
will need to her decoupled from its Apple historical roots or a parallel
non-Apple Foundation will need to be developed. We all know how difficult
and painful it is to maintain two different code sets that do mostly the
same thing. My humble recommendation is that we start looking at decoupling
foundation from its roots and a good first step would be to remove the NS-
prefix. This change would do many positive things, including alerting
developers that change is coming.

A long-term concern that I have is that if you do not begin the enormous
task of at least beginning to remove Apple-centric dependencies, then
sometime down the road someone outside the Apple environment will fork
Swift and take it in ways out of our control.

In short, I am in favor of at least beginning the move toward removing
NS- from Foundation.

On May 8, 2016, at 11:16 AM, Josh Parmenter via swift-evolution < >> swift-evolution@swift.org> wrote:

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

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 >> <swift-evolution@swift.org>>> wrote:

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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org
<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