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

[Greg Parker]

> On Dec 8, 2015, at 10:11 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Dec 8, 2015, at 4:09 AM, Fabian Ehrentraud via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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.

I'm not sure that Apple will get all of its headers audited in a timely manner either. Platform APIs have long tails.

This would make bring-up of a new platform awfully painful, too. You wouldn't be able to do anything with your shiny new port of Swift without annotating a bunch of that platform's headers somehow.

Measuring the impact of not-importing or ugly-importing unannotated API should be a straightforward experiment using a modified Swift importer. 
1. Hack the importer to record every un-annotated API that it sees.
2. Run the custom importer against some platform's SDK.
3. Look at the results and try to imagine how bad the world would be if those APIs were harder to use or missing entirely.


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler