[swift-evolution] Dropping NS Prefix in Foundation

[Xiaodi Wu]

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