Black Pixel has been an early user of Swift. We started a project developed entirely in Swift back in August and recently released it into the wild. It is a staggering 70K lines of code. Upon starting the project, everyone stated, with much trepidation and fear: “I don’t know Swift.” Obviously, this was the case for everyone. Inevitably, they adapted and started to say, “Hey, this is okay. I am getting the hang of Swift.” Swift changed, we rolled with it. It changed again, we kept rolling. These changes made us all stronger.
And the thing is, we were making up the coding idioms as we went. We started out writing Perfectly Good™ Objective-C code, but in Swift. There are differences in the syntax to be sure, but they seemed more like sugar than anything else. As time went on, our code started looking more and more Swift-ian in nature. More ways of expressing ideas in Swift, more idioms, appeared and adapted. Swift changed, we rolled with it. It changed again, we kept rolling. These changes made us all stronger.
It is my contention that Swift allows writing code that is difficult to do in Objective-C. That is not necessarily true; the same ideas are doable, but the ways to accomplish them are different and it is sometimes hard to see the translation. For example, Swift has Generics and first-class Enums — both of which take some thought on how to implement them similarly in Objective-C. On the other hand, Objective-C has Key Value Observing, which is not nearly so complete in Swift as it is in Objective-C. Many more differences exist; they are different languages after all.
By the way, the latest drop of Objective-C has added a simple form of Generics to the collection classes NSArray, NSDictionary, and NSSet. This is great, and will only increase the inter-operativity between the two languages. Honestly, it’s completely to support Swift inter-operativity and provide a better experience for Swift users when using Cocoa/Touch frameworks.
Swift 2 introduces several new additions that actually begin to impede the Perfectly Good™ Objective-C assertion. They are the guard statement, expanded use of the case clause to bring pattern matching to more control flow statements, Error Handling requirements, and Protocol Extensions. Not only are these changes important for Objective-C users to understand when switching to Swift 2, Swift 1 users also need to be aware of them.
Essentially, the guard statement is giving a common paradigm/idiom full language level support. The idea is that one checks for a condition early in a method, and if the condition is false, then an early exit is taken. The interesting aspect of guard is that the compiler enforces the early exit, the lack of which is a common error with this coding idiom. The guard statement might not be a true Game Changer™, but it does aid in Swift’s goal of reducing common errors.
Swift 1 introduced an incredibly powerful pattern matching capability to the common switch statement found in many other languages. Swift 2 brings this capability to the other control flow statements (if, while, guard, and for-in). This is simply amazing and will bring conceptual changes to how we write Swift (new idioms, as it were).
Protocol extensions are a big addition to the language. This allows users to provide default behavior to protocols themselves rather than requiring the definitions to be on each conforming type. Several global functions in the Swift 1 standard library are now in a protocol extension. The discoverability (and in a sense, use) of these once global functions has gone up. This is a change in the language and consequently in how people will conceive solutions (new idioms, as it were).
Finally, Swift 2 introduces an Error Handling paradigm. It appears that several of the common Objective-C error handling conventions are deterministically convertible to the new Swift paradigm. In fact, the mechanism that displays the framework headers in Swift already does this conversion. Since this is enforced in the compiler, many common errors dealing with handling application logic errors (eek, say that 10 times fast) are reduced. Just like Swift 1 forced users to confront and handle nils, Swift 2 makes users confront and handle errors. This is a large change and the old memes are replaced with new ones.
There is a strong feedback loop between the language one uses, the thoughts one can conceive in said language, and the memes comprising the culture surrounding said language. When a language changes, the thoughts and memes must perforce change too. Swift is a young language. It is exciting to be around, to see it evolve, to participate in its evolution. These recent changes and additions will make us (the language and the users of the language) all stronger.