relates to:

• SR-223 Option to assume ObjC return values are always nullable

Issue Description:

Introduction

Objective-C code that does not yet include nullability annotations should generate warnings for unsafe accesses in order to prevent runtime crashes.

Motivation

Swift code accessing Objective-C methods can easily crash. If the Objective-C code does not include nullability attributes, it is brought as Implicitly Unwrapped Optional (IUO) into Swift. If the value of the IUO is accessed, and it is nil at that time, a crash occurrs. These unsafe accesses do not produce compiler warnings and can not be identified by only looking at the according Swift code. So these problematic places are not easy to track down in a code base.

Short example:

// Objective-C  
- (NSString *)giveMeAString { return nil; }  

// Swift  
func thisWillCrash() {  
   let string = someObjectiveCObject.giveMeAString()  
   let length = string.length // crash  
}

Use cases

This affects all uses of Objective-C code from Swift, may it be the System SDK, an integrated Framework, or the same application's code.

Very important would be the use case of an application that is written in Objective-C where Swift code is added. The new Swift code (e.g. in an extension to an Objective-C class) is bound to call a lot of the application's old Objective-C code.

Example:

func someSwiftFuncInAnExtension() {
    myDataModel.someProperty.someMethod()
}

In a call like that it is not immediately obvious if myDataModel , someProperty or someMethod is written in Objective-C and missing nullability annotations. Swift should help with writing safe code and be supportive at gradually migrating an application to Swift.

Proposed solution

Additional warnings shall be added when implicitly unwrapping an IUO that was inferred from a lack of nullability information in the Objective-C API.

Example:

// Objective-C  
- (NSString *)giveMeAString { return nil; }  

// Swift  
func someFunction() {  
   let string = someObjectiveCObject.giveMeAString()  
   let length = string.length // warning  
   let length2 = string!.length // no warning  
   if let unwrappedString = string { // no warning  
       let length3 = unwrappedString.length
   }
}

Detailed design

• Create 2 separate warnings when implicitly unwrapping an IUO that was inferred the from a lack of nullability information in the Objective-C API - one for "system" and the other for "user" frameworks

• The warning levels shall be NO , YES and YES_ERROR

• The warning for "system" frameworks shall default to NO , the one for "user" frameworks to YES

• Xcode Fix-It in case of a compile error

Impact on existing code

The new warnings will not harm productivity. If a project has "Treat warnings as errors" activated, and there are issues with "user" frameworks, that warning could be selectively deactivated if fixing the errors would take too much time.