CODEWITHSUNDEEP
iosdesign-patternsswiftoption-type
Taylor Halliday
Taylor Halliday

Reputation: 640

Implicitly Unwrapped Optionals in Initialization - Swift

When writing a new swift class, I'm still not 100% comfortable when (not) to use implicitly unwrapped optionals as opposed to just plain optionals. As far as I can tell, it should be ok to assign something as implicitly unwrapped (and optional) if you never expect it's value to be nil. If it is nil, it's an exceptional event and should cause a runtime error.

Take, for example, this simple sign-in view that contains two textfield member variables:

class SignInFieldView : UIView {

var emailField: UITextField!;
var passField: UITextField!;

required init(coder aDecoder: NSCoder) {
    super.init(coder: aDecoder);
    commonInit();
}

convenience override init(frame: CGRect) {
    self.init(frame: frame);
    commonInit();
}

func commonInit() {
    layoutEmail();
    layoutPass();
}

// MARK: Layout Text Fields

func layoutEmail() {
    let rect = CGRect(x: bounds.origin.x, y: bounds.origin.y, width: bounds.size.width, height: (bounds.size.height * 0.5));
    emailField = UITextField(frame: rect);
    addSubview(emailField);
}

func layoutPass() {
    let rect = CGRect(x: bounds.origin.x, y: bounds.origin.y + (bounds.size.height * 0.5), width: bounds.size.width, height: (bounds.size.height * 0.5));
    passField = UITextField(frame: rect);
    addSubview(passField);
}
}

In the above class, both emailField and passField are classified as implicitly unwrapped optionals because I never expect them to be nil throughout the life of their superview. I don't assign them as constants because I want their initialization to be dependent on the state of the superview (frame / bounds / etc). I left out that extra code to keep this example clean.

Is using implicitly unwrapped optionals for members of initialization a proper and valid use?

Upvotes: 2

Views: 828

Answers (1)

Antonio
Antonio

Reputation: 72750

I'd stay away from implicitly unwrapped optionals unless there is a good reason to use them. Use non optional, when possible, otherwise optionals. Implicitly unwrapped are very dangerous if improperly used because they bypass the compiler check and generate runtime exceptions.

Non exhaustive list of cases when to use implicitly unwrapped:

  • when there's an API returning an implicitly unwrapped
  • to solve the Strong Reference Cycles Between Class Instances problem
  • when you have a class/struct property that (by design) will never be nil, but it cannot be set in the initializer

A typical case of the latter usage is in a UIViewController, when a property is initialized in the viewDidLoad method rather than in an initializer - it makes sense to use an implicitly unwrapped.

Do not use implicitly unwrapped in this cases:

  • because it's cool
  • because it lets you save a key press on the keyboard
  • when you are not 100% sure whether to use it or not

In your specific case, although the properties are instantiated in the initializator, they depend from the superclass initialization, so it makes sense to declare them as implicitly unwrapped.

Upvotes: 5

Related Questions