<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Dec 12, 2015, at 1:13 AM, Fabian Ehrentraud <<a href="mailto:Fabian.Ehrentraud@willhaben.at">Fabian.Ehrentraud@willhaben.at</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<div><br>
</div>
<div>Am 12.12.2015 um 06:03 schrieb Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Dec 11, 2015, at 12:08 AM, Fabian Ehrentraud <<a href="mailto:Fabian.Ehrentraud@willhaben.at" class="">Fabian.Ehrentraud@willhaben.at</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">
<blockquote type="cite" class="">
<div class=""><br class="">
On 10.12.2015, at 23:28, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<br class="Apple-interchange-newline">
On Dec 10, 2015, at 1:22 PM, Fabian Ehrentraud <<a href="mailto:Fabian.Ehrentraud@willhaben.at" class="">Fabian.Ehrentraud@willhaben.at</a>> wrote:<br class="">
</blockquote>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class=""><br class="">
</div>
</blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">
<blockquote type="cite" class="">
<div class="">
<blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<blockquote type="cite" class="">Most of the implicitly unwrapped optionals we currently get from (Objective-)C APIs can, in fact, never be nil. Forcing programmers to deal with all of these values as full optionals leads to a ton of optional-related boilerplate
that doesn’t actual help users write better code. Rather, it dilutes the effectiveness of optionals as a language feature: optionals should mean “nil matters here, think about it carefully!”. But if some large number of optionals people deal with on a day-to-day
basis are instead “the compiler didn’t know, so you have to write !”, the useful meaning of the “true” optionals gets lost in the noise.<br class="">
</blockquote>
<br class="">
I think exactly the opposite. If an API has not yet been audited, the client needs to consult the documentation if a return value can ever be nil. If not, she might explicitly and knowingly unwrap the value safely or non-safely. I deem this a good thing, as
it prevents unknowingly unsafe use. I do not think that it would get in the way, as the syntactic sugar for Optionals is quite minimal. Also when the API gets audited for nullability later on, the compiler will hint which optional unwrappings have been rendered
unnecessary.<br class="">
</blockquote>
<br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">You’re
discounting my main argument, which is that the safety provided by optionals is contingent on the nil case being interesting most of the time. That’s generally true in “pure” Swift code—Swift programmers use optionals when nil matters—and it’s generally true
in imported (Objective-)C code that has been audited, but your change would create a lot of optionals where “nil” isn’t actually interesting in practice.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Have I understood it right that your argument is that defaulting to Optionals would would make them loose their meaning and result in programmers just use ! too often, also in cases where the nil case should properly be handled? I see the point.
And I'm thankful for this constructive discussion.</div>
<div class=""><br class="">
</div>
<div class="">Nonetheless I think that Swift preventing unintentional mistakes would be something to strive for. Have you got alternative ideas on how to deal with the issue this proposal tries to address?</div>
</div>
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">I honestly don’t have alternative ideas here—implicitly unwrapped optionals is the best solution that we could find to balance the goals of making it easy to write correct code vs. not pushing too much boilerplate on users, and while I want to
continue to make them less common in Swift, I don’t think changing the Clang importer is the right answer.</div>
<br class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>- Doug</div>
<div class=""><br class="">
</div>
</div>
</blockquote>
<br>
<div>Would it be technically possible to have a different behavior for Cocoa APIs vs. own Application Code and integrated 3rd-party Frameworks?</div></div></blockquote><div><br></div>Somewhat. One can distinguish between "system" and "user" frameworks. <div><br><blockquote type="cite"><div>
<div>The Cocoa API is pretty well documented, and I think IUOs don't hurt too much there, as opposed to the other two. Also if nullabillity annotations are missing from the latter two, they can be added. So the necessary boilerplate !/? would remind the users
in a safe manner. </div>
<div><br>
</div>
<div>I'm unhappy with defaulting to IUOs as it has a bad impact on mixed projects. In pure ObjC it was expected that nil could be returned but mostly ignored as it could not hurt if methods were called on it, so not too many crashes arose. In a pure Swift project
one can stay away from IUOs and avoid that nil issue alltogether if one stays away from forced unwrapping. But as soon as the two are used together, for example when migrating to Swift, crashes can be hidden in every line. And there are no compiler warnings,
no analyzer inspections or anything that can help to find these lines. </div>
<div><br>
</div>
<div>That said, here is an alternative idea. A new compiler warning "Access to Objective-C method/function/property/initializer that misses nullability annotations". I guess this warning should not be shown for Cocoa APIs. </div>
<div>Would this result in even more work than the original proposal? </div></div></blockquote><div><br></div><div>No, it's easier because warnings (especially opt-in ones) have far less impact on existing code. I think what you're asking for is a warning when implicitly unwrapping an IUO when we inferred the IUO from a lack of nullability information in the Objective-C API. For me, that's no longer even a language proposal: it's a smallish proposal for an opt-in warning. </div><br><blockquote type="cite"><div><div>Would it harm productivity if "Treat warnings as errors" is activated?</div>
</div></blockquote><br></div><div>If it's opt-in or one can selectively downgrade it to a warning, it shouldn't harm productivity.</div><div><br></div><div> - Doug</div></body></html>