Should all object variables be optional in Swift?

Question

The Swift Programming Language book does not discuss this, but should all object variables be optional in Swift? Since technically speaking, creating an object may fail and return nil (as in the case of Objective-C). So should all optional variables of the Swift class object be declared for Swift (or at least for all Foundation classes)?

 let obj:NSData? = NSData() 

Answer 1

This may be an opinion based, but I think you usually want variables not to be optional. There are not many object initializers that can actually return nil .

In Obj-C, you do not check if all nil initializers are returned.

 NSArray *array = [[NSArray alloc] init]; if (array != nil) { //would you test this? } 

In the same way, do not allow all object variables to be optional in Swift. Only those when you really want to check for nil values.

By the way, in pure Swift, Object initializers cannot return nil , because in reality they do not have a return value. In Swift, object initialization cannot fail, so we are only talking about Obj-C interoperability here.

One example of a response to comments:

 NSData *data = [[NSData alloc] initWithContentsOfFile:@"some_file"]; 

in Swift:

 var data = NSData(contentsOfFile: "some_file") 

If the file does not exist, in both languages ​​we get a nil . In Swift, we have an implicitly deployed option, so the assignment itself will not fail, and we can still check nil if we want.

If we expected data to be nil , the behavior would be the same in both languages, we would sort of solve the problem. If we did not expect this, this is a mistake, because everything else is undefined behavior .

In Swift, the application will crash - the first time you use data . In Obj-C, the result will be completely random - note that we never expected data be nil , so our next statement could be:

 [array addObject:data]; 

application crash.

However, due to the nature of Obj-C, thousands of statements can occur before the error is detected on its own, and it may seem very strange - for example: data analysis may fail, the user interface layout will fail, because the elements will be missing when we expect them and so on. We can also get a late crash. However, the behavior of the application will be undefined, since the return is nil , because we did not take this possibility into account:

... things may not be executed, but this, of course, will not cause the program to crash or leave things in an unstable state ...

Both statements from the comment are false.

The late manifestation of errors is one of the biggest problems when debugging Obj-C applications, which makes them unsafe. Sometimes they do not crash, but that does not mean that they work correctly. Swift also considers an early crash a much better alternative than a nil hidden object that propagates through the application and the application’s hour failure.