<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div><span style="background-color: rgba(255, 255, 255, 0);">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. </span></div>
<div><br>
Am 08.12.2015 um 17:41 schrieb Michael Buckley via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr"><span style="font-size:13px">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.</span>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">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.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Dec 8, 2015 at 8:31 AM, Michael Buckley <span dir="ltr">
<<a href="mailto:thebuckley@gmail.com" target="_blank">thebuckley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div><br>
</div>
<div>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.</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Dec 8, 2015 at 7:45 AM, Javier Soto via swift-evolution
<span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
In practice, many developers will work with Apple's frameworks, and Apple has done a great job tagged all/most of their APIs!
<div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Dec 8, 2015 at 4:09 AM Fabian Ehrentraud via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<br>
I created issue SR-104 for this, but as suggested by Jordan Rose it should be discussed on this mailing list first.<br>
<br>
Short example:<br>
<br>
// Objective-C<br>
- (NSString *)giveMeAString { return nil; }<br>
<br>
// Swift<br>
func thisWillCrash() {<br>
let string = someObjectiveCObject.giveMeAString()<br>
let length = string.length // crash<br>
}<br>
<br>
The ClangImporter could handle this issue in several safer ways:<br>
<br>
1. Only import declarations that are nullability annotated (as proposed by Greg Parker)<br>
Positive side effect would be that it would motivate to write nullability annotations.<br>
<br>
2. Import un-annotated code as Optional<br>
Values would need to be unwrapped every time, which does not hurt too much due to the easy use of the `?` syntactic sugar.<br>
<br>
What do you think? Would this make Swift more safe when used together with Objective-C?<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote>
</div>
</div>
</div>
<span><font color="#888888">
<div dir="ltr">-- <br>
</div>
Javier Soto <img src="https://u2002410.ct.sendgrid.net/wf/open?upn=HDu-2BON2WuckNVJ2U1s3AlFgVD2xwU1HZRuo94MM4tGvjaZG5CpQBmU-2By1Rtk8ego-2F9FBe6JtVP7gjPOERN3JaGvE44LoSVMmyzfsjgoYvj9U4hfrAHrmfHtcnmw9Qt9f0PsgmYSFElsjq-2B1PXuB0NmFbmF48-2F3kFtqQhRKB9VcUNuwE8MlkkllLRcvuxNXpBnybimEEPVdg8ORDlmsqSwsm08cjM-2Fli8OYJSEnRupY0-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</font></span><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=z8-2FItS9d607zlxyiqd-2BXa09jaXmO60VXV2wLjA8i2wkMeLRZISXN6HvdgLTJTtPHtxh6aiHZd99mcFfVeQcTulsftDXP5hnDRJKY-2FZ6l5h3mmA-2FVJoIdG0zLCV7Oiw5ekLgNCnZb-2BRAst29H-2BjPtEZIFlVACWhIUAq85vIoW0rKW-2B09zbN88ozQWANCMhTM5R9JBka0UR10dnub6yV7svePwA9jj-2FlgspdxevnZKiUo-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>swift-evolution mailing list</span><br>
<span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br>
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br>
</div>
</blockquote>
</body>
</html>