Hardwired Objective-C Syntax That We Should Unlearn for Swift
While exploring the new and still changing Swift programming language, I found myself trying to instinctively add @ symbols and square brackets all over my code. The truth is that Apple tried to prepare us for these changes, but we never knew how big the changes were going to be. Here is some basic everyday Swift syntax that is different from Objective-C:
No semicolons at the end of the line 1
I was not sure how I feel about this one and I could tell others were having the same problem. Many developers at WWDC were not excited about this feature. That being said, now that I got to write some actual code, I am starting to get used to it. I don’t think I will miss the semicolons.
Literals
When NSNumber, NSArray and NSDictionary literals were introduced two years ago, everyone took it as Apple preparing Objective-C for a big makeover. Well, the makeover tuned out to be a total replacement. Swift also has literals for its collection types, but they all use square brackets and lose the @ sign.
Dot Syntax
No more calling methods with surrounding square brackets. Like it or not, Swift uses only the dot syntax.
Bools
The BOOL type is a distinguishing characteristic of Objectice-C. Using YES and NO as values is an interesting feature, but Swift uses the more popular and compatible true and false.
And finally…
The opening curly bracket goes on the line of the function name
OK. This is a not syntax, but I think we finally have a convention on where we should put the opening curly bracket. There was never an officially defined rule for this and even the example code and templates that Apple shipped were not consistent.
As Objective-C is not going away any time soon, I imagine there will be some discomfort from having to use both languages at the same time and in the same project. I don’t think that this is going to lead to a decrease in productivity, but the ability to quickly switch context is useful skill nowadays.
-
Putting a semicolon at the end of the line will not cause an error and will be ignored. However the new conventions discourage from using it. ↩