Rick Rolled & Swift 2

There was a nice thunderstorm moving through my area on the night of the WWDC 15 keynote. That or the possibility that Apple was getting a lot of requests for the stream gave me many pauses. Usually they were timed to perfectly align with a good line by whoever was speaking at the time. During the demonstration of Safari for El Capitan, there was a cleverly placed “Rick Roll” to demonstrate muting the audio of a tab. I hope Apple realizes the gravity of the situation. At any rate, this was the clue to go to the Apple Developer Site and see what was new there.

There is a lot. Rather than enumerate the changes, I’ll just point to them. https://developer.apple.com/support/transition/ . I think this will make things easier. I also expect that people will now be very happy that they don’t have to pay for a membership to test their iOS apps on a device. This is a huge improvement. I’m sure I will be enjoying the upgrade. I haven’t read the new agreements yet. I tend to click through those things. But they are in my downloads folder.

What the big news is for me is Xcode 7. Finally there is exception handling in Swift. Except there is no finally. Damn I’m bad with jokes. Anyway, I’ve updated a project I’m working on to use the new Swift 2 syntax in Xcode 7. So far, the changes are not shocking because I’m not very far along with it.

So. Exception handeling. I was rather hoping for a Java style syntax which looks like this:

try {
    // stuff that may throw an exception
}
catch exception_type {
    // handle exception
}
catch another_exception_type {
    // handle exception
}
...
catch all {
    // handle lost cause
}
finally {
    // any cleanup code that needs to execute regardless
}

Presumably any stack unwinding that goes on will be in the thread that the exception is tried from (as opposed to stuff in the try clause executing code on another thread). Dancing around in threads makes things more interesting but is manageable. Objective-C has @try/@catch/@finally that will work with C++.

The throws/throw declarations and syntax appear to be sensible enough for either the above try/catch/finally arrangement and the one that Swift went with which is sort of like C++ except with an extra word (copied from the new Swift Reference):

do {
    try vend(itemNamed: "Candy Bar")
    // Enjoy delicious snack
} catch VendingMachineError.InvalidSelection {
    print("Invalid Selection.")
} catch VendingMachineError.OutOfStock {
    print("Out of Stock.")
} catch VendingMachineError.InsufficientFunds(let amountRequired) {
    print("Insufficient funds. Please insert an additional $\(amountRequired).")
}

It is worth mentioning that there is a defer clause available in the Specifying Clean-Up Actions section of the language reference.

You use a defer statement to execute a set of statements just before code execution leaves the current block of code. This lets you do any necessary cleanup that should be performed regardless of whether an error occurred. Examples include closing any open file descriptors and freeing any manually allocated memory.

defer statement defers execution until the current scope is exited. It consists of the deferkeyword and the statements to be executed later. The deferred statements may not contain any code that would transfer control out of the statements, such as a break or a returnstatement, or by throwing an error. Deferred actions are executed in reverse order of how they are specified—that is, the code in the first defer statement executes after code in the second, and so on.

The example given is:

func processFile(filename: String) throws {
    if exists(filename) {
        let file = open(filename)
        defer {
            close(file)
        }
        while let line = try file.readline() {
            /* Work with the file. */
        }
        // close(file) is called here, at the end of the scope.
    }
}

The above example uses a defer statement to ensure that the open(_:) function has a corresponding call to close(_:). This call is executed regardless of whether an error is thrown.

This may actually be better. You can chain the catches on type thrown. You can also prevent error propagation using try! instead of the regular try.

Since functions are proper types (AKA closures), this will avoid the thread dance as the code will be executed in the same lexical scope and thread. I’m being a little imprecise here, but I think you know what I mean. The functional style of the defer statement should keep the Swift programmers that use functional programming patterns a lot happy.

There is of course more to go through. Apple will be Open Sourcing Swift. That got a lot of applause. Linux will be supported which is brilliant because Swift would make a great programming language for server side applications. Linux is very popular on servers. The success of Swift on Linux will largely depend on the licensing model that Apple chooses. I expect Apple will want to retain control over the language itself rather than going through a traditional standards body. That is simply speculation on my part. But this has been the case with Java, C#, and rather a lot of other languages.

Published by

David S

David Steuber

I'm the administrator of this facility.

One thought on “Rick Rolled & Swift 2”

Comments are closed.