Hello, The discussion we had previously on this mailing list made it quite clear that:
- Objective-C Foundation is the framework that is supposed to be used on all Darwin platforms, - swift-corelibs-foundation will be the Foundation framework for all other platforms, - Both frameworks will evolve slowly together. Therefore, it makes sense that for code written against Foundation to be portable, the swift-corelibs-foundation APIs and behavior needs to be identical to Darwin Foundation. Hence the following questions? - Shouldn't we be writing tests in a way so that they can be run against Darwin Foundation and have the CI Server run them? For example: while working on NSProgress, I write a bunch of tests against Darwin Foundation, make sure they pass, then copy-paste them in the CoreLibs project, and fix the implementation until they pass. This makes sure that both APIs are consistent with each other. I was thinking that we ought to automate this and have the CI server test them. - How are we planning to reconcile the API differences between both frameworks? For examples, one of my tests will run against CoreLibs but not against Darwin because NSThread.init takes a closure as argument in CoreLibs but a target+selector in Darwin. This is just one example, but I guess they are other inconsistencies elsewhere. This seems to be particularly the case with APIs that rely on the Objective-C runtime. In general, I'm starting to worry about the state of Foundation from a portability point of view. Once Swift 3 is released, I want to start writing portable swift code that relies on Foundation. And it seems like this will require a huge amount of #if os() everywhere to cope with the differences. David _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
