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

[Michael Buckley]

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>
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> 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> 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
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> --
>> Javier Soto
>> _______________________________________________
>> swift-evolution mailing list
>> 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/827e6227/attachment.html>