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

[Fabian Ehrentraud]

Good point about old frameworks in case of #1. Maybe a compiler option to deactivate the new behavior would help in the transition phase until the external dependencies are updated with nullability specifiers? Nonethelesd #2 does sound better in this case.

Am 08.12.2015 um 17:41 schrieb Michael Buckley via swift-evolution <swift-evolution at swift.org<mailto:swift-evolution at swift.org>>:

Given the availability and prevalence of nullability annotations, I think it's reasonable to update this behavior, but while I suspect most Swift projects that only use Apple-supplied Objective-C frameworks, there will still be a considerable number that rely on third-party, possibly closed-source frameworks. It may not be possible or economical for those projects to get updated versions of those frameworks with nullability attributes. If we choose option #1, these projects may be forced to rewrite their Swift code in Objective-C, or write extra Objective-C wrappers with nullability annotations around their existing code. For this reason, I recommend option #2.

Because this change will already require these projects to change their swift code, we should make the process as painless as possible, so this change should include support for automatic code migration, as well as nice error messages which both explain the change and how to fix it.

On Tue, Dec 8, 2015 at 8:31 AM, Michael Buckley <thebuckley at gmail.com<mailto:thebuckley at gmail.com>> wrote:
Given the availability and prevalence of nullability annotations, I think it's reasonable to update this behavior, but while I suspect most Swift projects that only use Apple-supplied Objective-C frameworks, there will still be a considerable number that rely on third-party, possibly closed-source frameworks. It may not be possible or economical for those projects to get updated versions of those frameworks with nullability attributes. If we choose option #1, these projects may be forced to rewrite their Swift code in Objective-C, or write extra Objective-C wrappers with nullability annotations around their existing code. For this reason, I recommend option #2.

Because this change will already require these projects to change their swift code, we should make the process as painless as possible, so this change should include support for automatic code migration, as well as nice error messages which both explain the change and how to fix it.

On Tue, Dec 8, 2015 at 7:45 AM, Javier Soto via swift-evolution <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:
I think the decision to import Obj-C APIs with implicitly unwrapped optionals was a very pragmatic decision at the time. However, given it's been over a year (I think?) since the nullability specifiers have been available, I agree with you this could now be improved.

I personally prefer #2: it mimics the old Obj-C behavior ("calling a method on nil doesn't do anything and any method can take or return nil") if you use "?." everywhere. This would be somewhat cumbersome, but like you say would encourage library developers to add these specifiers.
In practice, many developers will work with Apple's frameworks, and Apple has done a great job tagged all/most of their APIs!

On Tue, 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.

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.

What do you think? Would this make Swift more safe when used together with Objective-C?
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org<mailto:swift-evolution at swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org<mailto:swift-evolution at swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution




_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org<mailto:swift-evolution at swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151208/a1693189/attachment.html>