9 karma · joined November 2, 2015
There has been discussion about statically typed errors on the evolution mailing list — some core team members said they may look into in the future and others seeming more doubtful of its usefulness.
Why do you think a typed error handling model is better than introspecting the error at the catch site, I’m not sure I buy it?
And the Swift runtime is pretty minimal, mostly used for storing dynamic type information, dispatching protocol methods, generating (unspecialised) generic types, checking conformances etc. It's mostly used by the compiler to add the dynamic features of the language; for example, the compiler observes the lifetimes of variables and inserts retain/release instructions, which are lowered down to a swift_retain or swift_release calls on the runtime instance. These functions are implemented in the runtime and do the manipulation of reference counts and deallocation.
https://github.com/apple/swift/tree/master/stdlib/public/run...
`for (l, r) in zip(c1, c2) {`
It is not simply motivated by making code concise, I would say `for num in collection.reverse()` is less error prone and clearer than `for (var i = collection.count; i >= 0; i--) { var num = collection[i] ... }`
The reverse collection iterator is computed lazily too, so there is no little perf overhead
And internally apple use other languages a lot, but frameworks like UIKit, AppKit, and many of the other public frameworks they expose in the SDK are objc, with foundation for example abstracting a lot of CoreFoundation C code.
Secondly, compilers are a very different programming task to developing GUI apps; the Swift team choosing to use it has nothing to do with Apple’s assessment of how you should write an application—Apple are the people who have been leading objc development (they own the objc IP) in the last 10 years and use it in all first party apps and many system frameworks.