3 ms·

I'm least clear about whether a clean break with Cocoa will be needed. Perhaps most parts of Cocoa that don't match well with Swift will just be given more natu

I'm least clear about whether a clean break with Cocoa will be needed. Perhaps most parts of Cocoa that don't match well with Swift will just be given more natural-feeling replacements? Obviously this can be complicated by dependencies, though.

Someone 10y ago
That would almost certainly lead to a break with Cocoa. Those, for Swift programmers, more natural-feeling replacements will be harder to call from Objective-C than an API designed for Objective-C would be. The only way to make neither side unhappy about it would be to provide two 100% equivalent interfaces, one for Cocoa and one for Carbon. That is unfeasible, so there will be differences. Even if they manage to write functionally and preformance-wise identical interfaces, not shipping them at the exact same time still would make the other side feel discriminated against. I expect the first Swift-only library to appear on iOS because, on that platform, Apple can know exactly how much new code uses which language. That makes timing the transition easier. I also expect people to write glue code to call it from Objective-C, but that will be a rear-guard action. A few years after that, I expect Apple to drop Cocoa. Deep below Swift, all the core stuff such as strings will still use the same code, but that will be hidden behind a Swift interface. After all, this is Apple, a company that isn't afraid to drop backwards compatibility. This is what happened with Carbon and Cocoa, too (how many years did that take?) It won't happen overnight, though. Swift first needs to gain a few features (dynamism, more reflection, a frozen ABI, to mention a few), and the tooling must mature. I think the first feature breaking interoperability with Objective-C may be a borrow checker, as that is something they have expressed interest in.

3 ms·

I'm least clear about whether a clean break with Cocoa will be needed. Perhaps most parts of Cocoa that don't match well with Swift will just be given more natu

by glhaynes 10y ago

Someone 10y ago
That would almost certainly lead to a break with Cocoa. Those, for Swift programmers, more natural-feeling replacements will be harder to call from Objective-C than an API designed for Objective-C would be. The only way to make neither side unhappy about it would be to provide two 100% equivalent interfaces, one for Cocoa and one for Carbon. That is unfeasible, so there will be differences. Even if they manage to write functionally and preformance-wise identical interfaces, not shipping them at the exact same time still would make the other side feel discriminated against. I expect the first Swift-only library to appear on iOS because, on that platform, Apple can know exactly how much new code uses which language. That makes timing the transition easier. I also expect people to write glue code to call it from Objective-C, but that will be a rear-guard action. A few years after that, I expect Apple to drop Cocoa. Deep below Swift, all the core stuff such as strings will still use the same code, but that will be hidden behind a Swift interface. After all, this is Apple, a company that isn't afraid to drop backwards compatibility. This is what happened with Carbon and Cocoa, too (how many years did that take?) It won't happen overnight, though. Swift first needs to gain a few features (dynamism, more reflection, a frozen ABI, to mention a few), and the tooling must mature. I think the first feature breaking interoperability with Objective-C may be a borrow checker, as that is something they have expressed interest in.