<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 10, 2016, at 4:45 AM, Антон Жилин 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 dir="ltr" class=""><div class="">First of all, I tried to change the original proposal to add actual @autounwrapped attribute to Swift.</div><div class="">Because "explicit is better than implicit" and consistency and so on.</div><div class=""><br class=""></div><div class="">Its authors did not pay much attention, and so I'm going to create a separate proposal for that purpose.</div><div class=""><br class=""></div><div class="">Next, implicitly unwrapped optional was designed purely for bridging to Objective-C (and now C).</div><div class="">Notation T! that is still used in Swift code, is misleading, because it's not an actual type.</div><div class=""><br class=""></div><div class="">So I also propose that T! notation is reserved for entities imported from Objective-C.</div><div class="">Swift code, which needs that behaviour, such as delayed initialization, will use @autounwrapped.</div><div class="">It's more clear and explicit about this being a property behaviour and not a type, with all consequences.</div><div class=""><br class=""></div><div class="">What do you think?</div></div></div></blockquote><br class=""></div><div>Hi Anton,</div><div><br class=""></div><div>I agree with you in theory, and this is definitely important to discuss. My main concern is about the readability impact that this will have on the readability of unaudited APIs. Here are two random unaudited examples, with the rules we have today:</div><div><br class=""></div><div>JSValue / Darwin:</div><div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><div style="margin: 0px; line-height: normal;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func defineProperty(property: String!, descriptor: AnyObject!)</div><div class=""><div style="margin: 0px; line-height: normal; min-height: 13px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func strcat(_: UnsafeMutablePointer<Int8>!, _: UnsafePointer<Int8>!) -> UnsafeMutablePointer<Int8>!</div></div><div style="color: rgb(52, 149, 175);" class=""><span style="color: rgb(0, 0, 0);" class=""><br class=""></span></div></div></div><div class="">If we got rid of !, we’d end up with:</div><div class=""><br class=""></div><div class=""><span style="font-family: Menlo; font-size: 11px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span></span><span style="font-family: Menlo; font-size: 11px;" class="">func</span><span style="font-family: Menlo; font-size: 11px;" class=""> </span><span style="font-family: Menlo; font-size: 11px;" class="">defineProperty(property:</span><span style="font-family: Menlo; font-size: 11px;" class=""> @autounwrapped </span><span style="font-family: Menlo; font-size: 11px;" class="">String?, descriptor:</span><span style="font-family: Menlo; font-size: 11px;" class=""> @autounwrapped </span><span style="font-family: Menlo; font-size: 11px;" class="">AnyObject?)</span></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func strcat(_: @autounwrapped UnsafeMutablePointer<Int8>?, _: @autounwrapped UnsafePointer<Int8>?) -> @autounwrapped UnsafeMutablePointer<Int8>?</div></div><div class=""><span style="color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class="">Here are some problems:</div><div class="">a) @autounwrapped ends up dominating the signature, since it is longer than many type names.</div><div class=""><br class=""></div><div class="">b) While it is appropriate for return values and properties, it isn’t the right attribute name for parameters. There, a better name would be “@unaudited”. When passing a parameter, there is no behavioral difference between T! and T? after all. </div><div class=""><br class=""></div><div class="">I suppose that you could argue that we should just drop annotations completely for parameters. My concern with doing that is that it would lose the distinction between audited APIs that accept nil and do something meaningful with it, and those that have been unaudited.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><span style="color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="color: rgb(0, 0, 0);" class=""><br class=""></span></div></body></html>