<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Some of this topic I am unqualified to comment on but I will try to address some of the concerns.</div><div class=""><br class=""></div><div class="">With the goal of matching the surface area of APIs and behavior that are important for cross platform development we can get very close no matter the backing language. In the areas that are potentially unknowns please feel free to ask questions for how things should be implemented or even questions of how the objective-c version works. Those types of discussions are absolutely fair game (to the most nitty gritty details).</div><div class=""><br class=""></div><div class="">For your example of NSSortDescriptor: that does have the reliance upon KVC and selectors which swift really does not have the introspection to do the KVC (beyond perhaps some simple cases) and selectors are not really a thing; we would have to change the API. KVC and KVO both were cut from the initial swift-corelibs implementation because we thought that they would not be something that could easily be implemented in Swift without features like property behaviors or other compiler/runtime support (and from swift-evolution there have been some discussions about even expressing key paths as something less stringy).</div><div class=""><br class=""></div><div class="">Would NSSortDescriptor be something that would be worthwhile to have if lets say it didn’t have selectors? Would it make sense as an implementation with generics to transact upon a protocol? Does it make sense as a reference type? Should it transact upon NSArray or Array?</div><div class=""><br class=""></div><div class="">Changing API is fair game, if there is something that you think is worth bringing to the table as a more swift friendly interface that would help all platforms (and perhaps even make the objc version better too). And we should discuss on what is the best path forward on those types of changes since some of the parties involved may span beyond those that work on the open source side of things.</div><div class=""><br class=""></div><div class="">The swift-corelibs-foundation definitely could use some performance boosts (I know for example the JSON and plist serialization implementations have some distinct bottlenecks) but I think our initial goals should be to get the surface area covered first and then after we can verify the behavior then performance optimizations can be made.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 14, 2016, at 5:57 AM, Kiel Gillard via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class="">Thanks for the reply and for pointing me to the design document.</div><div class=""><br class=""></div><div class="">I doubt that Foundation's dependency on the exclusive features of the Objective-C runtime would be so instrumental to the majority of its implementation details. I doubt things like algorithms and performance optimisations used in Foundation are each and every time exclusive to the ObjC runtime such that it justifies building a pure Swift implementation without respect to its ancestor. Perennial problems in computer science have their solutions in a variety of languages and runtimes. So even if a solution is dependent on the ObjC runtime, there may be a spiritual sibling to a solution.</div><div class=""><br class=""></div><div class="">For a simple example, I figured my first small contribution could be to the implementation of NSSortDescriptor. The API seems <span style="background-color: rgba(255, 255, 255, 0);" class="">straightforward and </span>doesn't suggest there's anything exclusive to the ObjC runtime (eg swizzling) going on. So if I was to provide most of this implementation, I would be doing so in the dark of any learnings from its release history.</div><div class=""><br class=""></div><div class="">Perhaps I need to suppress my sceptical feelings, trust Apple are making the right decision here (because, you know, given they are the ones privy to the source code!) and have faith that Apple won't eventually replace Foundation with a buggy and underperforming equivalent for Swift developers. But I am concerned for the quality of the platform and I desire to give the community the best work I can. I would like to know what the error in my concern is and if others in the community share this concern.</div><div class=""><br class=""></div><div class="">Kiel</div><div class=""><br class=""><div class="">Sent from my iPhone</div></div><div class=""><br class="">On 14 Apr 2016, at 9:11 PM, Alexander Alemayhu <<a href="mailto:alexander@alemayhu.com" class="">alexander@alemayhu.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 14 Apr 2016, at 02:32, Kiel Gillard via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello all,<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Hei,</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">I’m considering contributing yet part of me feels hesitant or reluctant to do so because I do not want to do a poor job at what feels like I’d be reverse-engineering the Foundation APIs (as opposed to Core Foundation and the pure Swift Foundation).<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Cool, I also want to contribute :)</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Perhaps I missed the answer somewhere else or maybe I’m lacking the imagination to come up with reasons myself, but why isn’t Foundation (as it ships in iOS and OS X now) open source, too?<br class=""><br class="">Wouldn’t a pure Swift implementation of Foundation benefit from insights from the implementation details of Foundation? For example, Foundation may have implemented such-and-such an API in a particular way for performance reasons that would be unacceptable if released. That insight may be lost by providing a Swift implementation of an API that merely reproduces the same output from the same input. Concretely speaking, I seem to recall such a conversation a few months ago or so with respect to the implementation NSJSONSerialization (unfortunately, I can’t seem to find the thread).<br class=""><br class="">I’m not suggesting a pure Swift Foundation should be a one-to-one port of Foundation’s implementation, but surely it would be helpful (not just for me, but for others too) to take the learnings of a mature API into account when implementing Swift Foundation?<br class=""><br class="">Thanks,<br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class="">If you haven’t looked at the Design Principles[0] for swift-corelibs-foundation consider reading it.</div><div class=""><br class=""></div><div class="">[0]: <a href="https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Design.md" class="">https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Design.md</a></div><br class=""></div></blockquote></div></div>_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></blockquote></div><br class=""></body></html>