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.
Yes, the swift runtime does stuff like heap allocation & reference counting for classes, type introspection (including `as` casts), error handling, as well as generating instances of unspecialised generic types, and dispatching (dynamic) protocol methods (and other witnesses, like computed properties).
You can use the zip function to loop through 2 collections.
`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
Yeah, I still wouldn’t say that c++ is “one of the most widely-used languages for writing native apps” for OS X.
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.
Most apple platform apps are written in mostly objc or Swift and not C++, I wouldn’t say it is one of the most widely used languages on these platforms by any means. The Cocoa SDK exposes an objc interface so many system framework calls have to use swift or objc.
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.