> On May 9, 2016, at 12:26 PM, Tony Parker <[email protected]> wrote: > > Hi Matthew (and others), > >> On May 9, 2016, at 9:03 AM, Matthew Johnson via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> Sent from my iPad >> >>> On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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. > > 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 > > - Tony > >> >>> >>> Cheers >>> Zach Waldowski >>> [email protected] <mailto:[email protected]> >>> >>>> 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 >>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>> >>>>>> <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 >>>>>> >>>>>> <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 >>>>>> [email protected] >>>>>> 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 >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> 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 >> >> _______________________________________________ >> 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
