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

[Fabian Ehrentraud]

Are there any objections to variant 2 "Import un-annotated code as Optional"? If not, I would create the proposal. 

> Am 09.12.2015 um 07:11 schrieb Chris Lattner <clattner at apple.com>:
> 
> 
>> 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