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