<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">I created the proposal, no PR yet. Is something missing / everything clear?</div>
<div class=""><a href="https://github.com/fabb/swift-evolution/blob/import_as_optional_by_default/proposals/0008-import-as-optional-by-default.md" class="">https://github.com/fabb/swift-evolution/blob/import_as_optional_by_default/proposals/0008-import-as-optional-by-default.md</a></div>
<div class=""><br class="">
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 10.12.2015, at 12:42, Fabian Ehrentraud via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Are there any objections to variant 2 &quot;Import un-annotated code as Optional&quot;? If not, I would create the proposal.
<br class="">
<br class="">
<blockquote type="cite" class="">Am 09.12.2015 um 07:11 schrieb Chris Lattner &lt;<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>&gt;:<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Dec 8, 2015, at 4:09 AM, Fabian Ehrentraud via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class="">
<br class="">
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.<br class="">
<br class="">
I created issue SR-104 for this, but as suggested by Jordan Rose it should be discussed on this mailing list first.<br class="">
<br class="">
Short example:<br class="">
<br class="">
// Objective-C &nbsp;<br class="">
- (NSString *)giveMeAString { return nil; } &nbsp;<br class="">
<br class="">
// Swift &nbsp;<br class="">
func thisWillCrash() { &nbsp;<br class="">
&nbsp;let string = someObjectiveCObject.giveMeAString() &nbsp;<br class="">
&nbsp;let length = string.length // crash &nbsp;<br class="">
}<br class="">
<br class="">
The ClangImporter could handle this issue in several safer ways:<br class="">
<br class="">
1. Only import declarations that are nullability annotated (as proposed by Greg Parker)<br class="">
Positive side effect would be that it would motivate to write nullability annotations.<br class="">
</blockquote>
<br class="">
This seems unfortunate to me, because it would severely hamper interoperating with Objective-C and *C* APIs that have not been audited. &nbsp;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.<br class="">
<br class="">
<blockquote type="cite" class="">2. Import un-annotated code as Optional<br class="">
Values would need to be unwrapped every time, which does not hurt too much due to the easy use of the `?` syntactic sugar.<br class="">
</blockquote>
<br class="">
This is a very interesting idea, one I haven’t considered recently. &nbsp;I agree with you that this is worth considering, and I would love to see IUO just get summarily deleted :-)<br class="">
<br class="">
-Chris<br class="">
</blockquote>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
https://lists.swift.org/mailman/listinfo/swift-evolution<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>