2 ms·

Don't know whether it's just because a lot of the library code hasn't been fully moved to this model yet, but I'm still finding most (possibly all) of the iOS A

Don't know whether it's just because a lot of the library code hasn't been fully moved to this model yet, but I'm still finding most (possibly all) of the iOS API code to use the same error:&error) approach that Objective C uses.

pohl 12y ago
I'm guessing you're right. Their veil of internal secrecy wasn't lifted until very recently, and their design does signal a longer-term transition is in play. The real work of modernizing the libraries probably began only after WWDC. There was a job listing posted to llvm-dev after the keynote that gives a few clues. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073669.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073669....
bronxbomber92 12y ago
That's because all of the existing frameworks are written in Objective-C. Rewriting the frameworks in Swift is probably an even bigger undertaking than the Swift language itself (and one can't just change the frameworks to fit Swift's idioms for compatibility reasons).
eridius 12y ago
Approximately none of the iOS APIs have been adjusted for Swift yet. Also, at least for Swift 1.0, they won't be. Swift does not guarantee a stable ABI right now or for 1.0. They guarantee binary compatibility with the OS, and ABI compatibility with any application frameworks that are compiled alongside the application (because, well, those can't change), but no compatibility between frameworks and applications. The only way to get that compatibility is to stick to Obj-C APIs (or, well, pure C APIs, but that's no better). What this means is system frameworks will not be able to take advantage of things like generics or multiple return types until sometime in the future, past Swift 1.0. Of course, they couldn't justify doing that today anyway, because they need to maintain Obj-C compatibility for all of the Obj-C code that still exists.

pohl 12y ago

I'm guessing you're right. Their veil of internal secrecy wasn't lifted until very recently, and their design does signal a longer-term transition is in play. The real work of modernizing the libraries probably began only after WWDC. There was a job listing posted to llvm-dev after the keynote that gives a few clues. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073669.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073669....

bronxbomber92 12y ago

That's because all of the existing frameworks are written in Objective-C. Rewriting the frameworks in Swift is probably an even bigger undertaking than the Swift language itself (and one can't just change the frameworks to fit Swift's idioms for compatibility reasons).

eridius 12y ago

Approximately none of the iOS APIs have been adjusted for Swift yet. Also, at least for Swift 1.0, they won't be. Swift does not guarantee a stable ABI right now or for 1.0. They guarantee binary compatibility with the OS, and ABI compatibility with any application frameworks that are compiled alongside the application (because, well, those can't change), but no compatibility between frameworks and applications. The only way to get that compatibility is to stick to Obj-C APIs (or, well, pure C APIs, but that's no better). What this means is system frameworks will not be able to take advantage of things like generics or multiple return types until sometime in the future, past Swift 1.0. Of course, they couldn't justify doing that today anyway, because they need to maintain Obj-C compatibility for all of the Obj-C code that still exists.