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 < [email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 < > [email protected]<mailto:[email protected] > <[email protected]>>> 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 > [email protected]<mailto:[email protected] > <[email protected]>> > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
