[swift-evolution] SR-104: Improve Crash-Safety when Importing Objective-C Code Without Nullability Attributes

[Chris Lattner]

> On Dec 8, 2015, at 4:09 AM, Fabian Ehrentraud via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Swift code accessing Objective-C methods can easily crash - if the Objective-C code does not include nullability attributes, the code is brought as implicitly unwrapped into Swift, where unsafe accesses do not produce compiler warnings.
> 
> I created issue SR-104 for this, but as suggested by Jordan Rose it should be discussed on this mailing list first.
> 
> Short example:
> 
> // Objective-C  
> - (NSString *)giveMeAString { return nil; }  
> 
> // Swift  
> func thisWillCrash() {  
>    let string = someObjectiveCObject.giveMeAString()  
>    let length = string.length // crash  
> }
> 
> The ClangImporter could handle this issue in several safer ways:
> 
> 1. Only import declarations that are nullability annotated (as proposed by Greg Parker)
> Positive side effect would be that it would motivate to write nullability annotations.

This seems unfortunate to me, because it would severely hamper interoperating with Objective-C and *C* APIs that have not been audited.  While Apple is keen to audit their APIs, I doubt that all the linux system headers will get updated in a timely manner and users don’t generally have a way to do anything about that.

> 2. Import un-annotated code as Optional
> Values would need to be unwrapped every time, which does not hurt too much due to the easy use of the `?` syntactic sugar.

This is a very interesting idea, one I haven’t considered recently.  I agree with you that this is worth considering, and I would love to see IUO just get summarily deleted :-)

-Chris