<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=""><blockquote type="cite" class="">On Mar 17, 2016, at 5:04 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">On Mar 17, 2016, at 4:18 PM, Chris Willmore via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Mar 17, 2016, at 2:29 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">I'm not sure this is a great idea yet. Punishing IUOs with verbose syntax may feel good, but runs the danger of making projected Swift interfaces from unaudited C and Objective-C APIs too noisy to read. Our current syntax was motivated by a strong desire to ensure that Swift interfaces remain readable, even for foreign APIs that haven't been annotated with Swift interop in mind yet.<br class=""></blockquote><br class="">I don’t think that Brent and I are suggesting that attribute syntax for IUOs should be mandatory or even recommended, merely that it should exist. That way we can talk about the feature in terms of the underlying attribute-based representation without it being some hidden, exclusively compiler-internal thing.<br class=""></blockquote><br class="">That's my position as well. I will probably almost always use the `!` sugar, but when I'm thinking about the feature, and perhaps occasionally when I'm doing something kind of tricky with it, having the desugared Optional + @autounwrap representation may come in handy.<br class=""></blockquote><br class="">I’ve updated the proposal to more explicitly call out the need for a named decl attribute. The name is subject to further discussion, of course:<br class=""><br class=""><a href="https://github.com/cwillmor/swift-evolution/blob/9dce2e8d6c1b27f3370e8c2ba8d5b549ab8f6954/proposals/0000-abolish-iuo.md" class="">https://github.com/cwillmor/swift-evolution/blob/9dce2e8d6c1b27f3370e8c2ba8d5b549ab8f6954/proposals/0000-abolish-iuo.md</a><br class=""></blockquote><br class=""><div class="">This is looking great, and I agree that explaining it in terms of an attribute makes sense. Some more comments:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">"This proposal seeks to remove the ImplicitlyUnwrappedOptional type from the Swift type system and replace it with an IUO attribute on declarations. Appending ! to the type of a Swift declaration will give it optional type and annotate the declaration with an attribute stating that it may be implicitly unwrapped when used.”</div></blockquote><div class=""><br class=""></div><div class="">This is more of a statement of implementation. I would start out with the first two sentences of your motivation, and then make a more direct statement about the purpose & payoff, something along the lines of:</div><div class=""><br class=""></div><div class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">"The ImplicitlyUnwrappedOptional ("IUO") type is a valuable tool for importing Objective-C APIs where the nullability of a parameter or return type is unspecified. It also represents a convenient mechanism for working through definite initialization problems in initializers. </div><div class=""><br class=""></div><div class="">This proposal aims to make the behavior of these values more simple, local, and predictable by making any force-unwrap operations happen locally, and only when necessary for an expression to type check.”</div></blockquote><div class=""><br class=""></div><div class="">With this change, your motivation section can be simplified or just merged into the intro.</div></div></div></blockquote><div><br class=""></div>My intent when writing the introduction was for it to serve as a summary of the proposal to follow. I feel like writing it like the above would bury the lede (i.e. the IUO type is going away).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This heavily implies a major syntax change, which you aren’t proposing:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">I propose demoting implicitly unwrapped optionals from being a first-class type in the Swift type system to being an attribute on declarations in Swift.</div></blockquote><div class=""><br class=""></div><div class="">How about something like:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">In this proposal, we keep the surface syntax of T! for these types, in the following locations <the list>. However, internally, the compiler will model this as a property of the declaration that it is applied to, not as part of the formal type system. No human would ever write or observe the attribute, but we will refer to them as @_autounwrapped (properties and parameters) and @_autounwrappedResult (function and subscript results).</div></blockquote></div></div></blockquote><div><br class=""></div><div>The concern about implying a syntax change is valid, and I’ve rewritten this section as a result. I don’t understand why we would propose separate @_autounwrappped and @_autounwrappedResult attributes, though. I figured the semantics of @_autounwrapped would depend on the kind of declaration that it is attached to — if it’s a function-like decl (i.e. function, method, initializer, or subscript), it applies to the result of the decl’s full application; otherwise, to the value of the decl itself.</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">What is the advantage to allowing someone to write the attribute?</div></div></blockquote><div><blockquote type="cite" class=""><br class=""></blockquote></div></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">It is possible to attach @implicitly_unwrapped to a declaration explicitly,</div><div class=""><br class=""></div></blockquote>It seems like this unnecessarily complicates the surface model of Swift. To me, it seems like there is no advantage to having two ways to spell this.</div></div></blockquote><br class=""><div>The main thing I had was consistency with other attributes. Are there currently any attributes that can’t be written explicitly like this? I agree that there’s no practical advantage, though.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Instead of:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">The effect of this behavior is that the result of any expression that refers to an IUO declaration of type T? will either...</div></blockquote><div class=""><br class=""></div><div class="">How about:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">The effect of this behavior is that the result of any expression that refers to a value declared as T! will either</div></blockquote></div></div></blockquote><div><br class=""></div>Yeah, that sounds better. Fixed.</div><div><br class=""></div><div>New draft: <a href="https://github.com/cwillmor/swift-evolution/blob/8f566a63d32dada678c9c0528abc8cbcf936398a/proposals/0000-abolish-iuo.md" class="">https://github.com/cwillmor/swift-evolution/blob/8f566a63d32dada678c9c0528abc8cbcf936398a/proposals/0000-abolish-iuo.md</a></div><div>Diff: <a href="https://github.com/cwillmor/swift-evolution/commit/8f566a63d32dada678c9c0528abc8cbcf936398a" class="">https://github.com/cwillmor/swift-evolution/commit/8f566a63d32dada678c9c0528abc8cbcf936398a</a></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Otherwise, LGTM!</div></div></div></blockquote><div><br class=""></div>Thanks!</div><div>— Chris Willmore<br class=""></div><br class=""></body></html>