Forced unwrapping vs not

Question

Facebook recently updated Parse to support Swift. One of the code examples it gives is this:

var gameScore = PFObject(className: "GameScore")
gameScore.setObject(1337, forKey: "score")
gameScore.setObject("Sean Plott", forKey: "playerName")
gameScore.saveInBackgroundWithBlock { 
(success: Bool!, error: NSError!) -> Void in
    if success {
        NSLog("Object created with id: \(gameScore.objectId)")
    } else {
        NSLog("%@", error)
    }
}

I'm curious about this part: "(success: Bool!, error: NSError!)", in particular the point of the exclamation marks. My understanding of optionals was something like this:

NSError: this is an NSError, and cannot be nil. NSError?: this might include an NSError or it might be nil, but it needs to be unwrapped first. NSError!: this is a force-unwrapped NSError?, and thus cannot be nil.

Facebook's example says that success is a Bool! and error is an NSError! - ie, they are both definitely provided. How come they aren't just written as Bool and NSError, providing that Facebook has unwrapped them before sending them on? Also, how can both success and error both be set? Traditional use of NSError would say that it's set to nil when there's no problem.

Answer 1

It's probabily due to interoperability with Objective-C APIs. Since any object can be nil in Objective-C, those two values have to be optional in Swift.

Anyway - since apparently they guarantee that those objects are never going to be nil - they can afford to implicitly unwrap them, allowing whoever uses this API to save a few unwraps, which is nice.

Concerning your statement

Traditional use of NSError would say that it's set to nil when there's no problem.

This is just wrong, even in Objective-C.

The BOOL/NSError pattern in Cocoa dictates that you have to check the success value to know whether an error occured, and - if that's the case - then the NSError will contain information about it.

Checking for NSError to be nil is a common misuse of this pattern, and it can lead to logic errors in your code, as some Apple APIs return a non-nil error even in case of success.