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

Fabian Ehrentraud Fabian.Ehrentraud at willhaben.at
Thu Dec 10 10:34:07 CST 2015

I created the proposal, no PR yet. Is something missing / everything clear?

On 10.12.2015, at 12:42, Fabian Ehrentraud via swift-evolution <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:

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<mailto:clattner at apple.com>>:

On Dec 8, 2015, at 4:09 AM, Fabian Ehrentraud via swift-evolution <swift-evolution at swift.org<mailto: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 :-)

swift-evolution mailing list
swift-evolution at swift.org<mailto:swift-evolution at swift.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/da3b4983/attachment.html>

More information about the swift-evolution mailing list