8 Surprises I learnt about Swift

Kristof Van Landschoot - December 14, 2015

Recently I did my first project in Apple's new programming language. I had read many blogposts and large parts of the specification but still some things struck me as surprising.

Most of these things will probably change over time. Some of them are little annoyances that are consequences of the way Swift is growing up in public. Some of them will be obvious to people that have followed the evolution of the language better than I have.

So, for what it is worth: here is my list.

  1. Xcode still has a hard time dealing with Swift

    If a method has not been typed correctly according to the syntax you can not command-click to the documentation. Often you will need to look up the documentation to type the syntax correctly before a command-click can get you to the documentation on how to write the syntax correctly. Chicken and egg.

    If you are used to find out who calls a certain method via that little menu on the top left of your file in Xcode, tough luck: in Swift this no longer works.

    Expect to have the compiler crashing when you get the syntax wrong. You might need to restart Xcode to get things working again.

  2. The compiler knows the type better than you

    In Swift you can write:

    let x = someFunction(y)

    and you can only find out what type x is by looking at the definition of the someFunction elsewhere in the code.

    Compare with Objective-C where you'd write:

    double x = someFunction(y)

    Now you see immediately that x is a double.

    The Swift compiler will not let you use x as anything else than a double while the Objective-C compiler would do a lot of implicit (unsafe) casting, so Swift is preferrable. Plus, you can always write:

    let x: Double = someFunction(y)

    and make your code a bit clearer to read.

    But, Ideally Xcode could tell you with a mouseover that x is of type Double, whether you wrote it or not. There should be no need to write it, as the compiler knows the type anyway and a reminder of x's type is always only a mouseover away.

  3. Another object tree

    I was surprised to find out that tuples are not AnyObjects. The reason is that AnyObject corresponds to an Objective-C object, an object that can exist in the Cocoa world.

    We still write apps in the Cocoa framework so mostly we deal with AnyObjects. And often times (in the case of strings for instance) there is implicit bridging between the two sorts of objects. Then there is also an Any object, which is not (necessarily) an AnyObject, but is the Swift equivalent of the Objective-C general object (represented in Swift by AnyObject). All very confusing, and inexplicably confusing if you consider that Swift had a chance to start with a clean slate.

  4. New String API

    I know, Unicode is hard. But the string API has changed so much (even between versions of Swift) that I think having just the possibility to get to know an API before it changes might be a feature in itself.

    To deal with attributed strings, for instance, there is no counterpart in Swift, so I ended up bridging strings more often than I should have needed to.

  5. Function parameter naming

    It is great that we can name all parameters to a function:

    func myFunction(firstConstant: Double, secondConstant: Double)

    ...

    myFunction(firstConstant: 3.14, secondConstant: 4.0)

    but since Swift has to be told the name of the paramaters, why is it not possible to call this function with the parameters in another order? Like this:

    myFunction(secondConstant: 4.0, firstConstant: 3.14)

    It would seem like the logical continuation of named parameters to me.

    The default behavior of having to write the first parameter name but not having to type the rest of the names (by default) is an unnecessary heritage from the Objective-C world which encourages further ugly function naming like

    functionWithParam1(param1: Double, param2: Double)

  6. Unstable language

    One of the main obstacles for using the language has been the fact that it has been growing up in public. Some code samples I found on the internet were obsolete and needed updating to a newer syntax. Not having followed the changes while they were happening made googling for solutions just a little bit more difficult.

  7. Optionals are great

    It took only a little bit of time to appreciate the safety that comes from having the safety that optionals bring. I know some people that have been arguing against optionals with a vengeance, but I can only guess their frustration comes from earlier versions of the language.

  8. Very good interop with Objective-C

    At any point in time you can still use Objective-C. I used a couple of frameworks that were still Objective-C (still using CocoaPods) and could extend them without many problems.

    But Dropbox is having a lot of problems because they decided to write a framework in Swift. I guess it is still too early for that. This is what happens when growing up in public: everybody shares some of the pain.