> On 14 Apr 2016, at 02:32, Kiel Gillard via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > Hello all,
Hei, > > 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). Cool, I also want to contribute :) > > 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? > > 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). > > 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? > > Thanks, If you haven’t looked at the Design Principles[0] for swift-corelibs-foundation consider reading it. [0]: https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Design.md <https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Design.md>
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
