<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="">Great to hear IUOs losing ground :-)</div>
<div class=""><br class="">
</div>
<div class="">Might adding additional compiler warnings as described in SR-104 accompany the implementation of this proposal well?</div>
<div class=""><a href="https://bugs.swift.org/browse/SR-104" class="">https://bugs.swift.org/browse/SR-104</a></div>
<div class=""><br class="">
</div>
<div class="">Fabian</div>
<div class=""><br class="">
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 31.03.2016, at 18:43, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Proposal Link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md" class="">
https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md</a><br class="">
<br class="">
The review of SE-0054 "Abolish ImplicitlyUnwrappedOptional type" ran from Mar 25…30, 2016. The proposal has been *accepted, pending implementation experience*:<br class="">
<br class="">
There is generally positive feedback on the proposal, as it keeps the good behaviors of the existing T! type syntax (including support for importing un-nullability-audited APIs, support for 2-phase initialization patterns, etc) while dramatically reducing the
confusion and surprise that they introduce as they trickle through type inference. The core team sees significant value in having a simple and predictable model that can be explained concisely.
<br class="">
<br class="">
That said, this is the sort of proposal that can have a profound impact on the actual experience using unaudited APIs. The core team believes that the experience will be good, but we would like to get some experience moving a couple of existing projects (both
low-level code that interacts with C, and an “App” project working with high level frameworks) to see what the impact is in practice. If something unexpected comes up, we will revisit this, and potentially reject it later. Chris Willmore is working on an
implementation of this now, so we should know in the next week or two.<br class="">
<br class="">
Thank you to Chris Willmore for driving this forward!<br class="">
<br class="">
-Chris Lattner<br class="">
Review Manager<br class="">
_______________________________________________<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>