<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Feb 19, 2016, at 1:10 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 19, 2016, at 2:04 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 19, 2016, at 12:17 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><b class="">> Here's a problem</b></div><div class=""><br class=""></div>* There are Swift attributes: @autoclosure, @available, @objc, @noescape, @nonobjc, @noreturn, @testable, @warn-unused-result, @convention, @noreturn.<div class="">* There are ObjC-ish/Xcode-ish attributes: @UIApplicationMain, @NSManaged, @NSCopying, @NSApplicationMain, @IBAction, @IBDesignable, @IBInspectable, @IBOutlet</div><div class="">* There may be user-definable attributes under SE-0030: for example @lazy, @delayed; these are certainly attribute-ish, and it makes sense to present these using attribute-syntax.</div><div class="">* The attribute syntax using `@` has had an intention "to open the space up to user attributes at some point"</div><div class=""><br class=""></div><div class=""><b class="">> Namespacing</b></div><div class=""><br class=""></div><div class="">If Swift were to start accepting user-defined attributes, it would need some way to differentiate and namespace potential conflicts. The most obvious solution looks like this:</div><div class=""><br class=""></div><div class="">`@Swift.autoclosure`, `@UIKit.UIApplicationMain`, `@UIKit.IBOutlet`, `@Swift.noreturn`, `@Custom.lazy`, etc.</div><div class=""><br class=""></div><div class="">Cumbersome, ugly, problematic.</div><div class=""><br class=""></div><div class=""><b class="">> Modernization</b></div><div class=""><b class=""><br class=""></b></div><div class="">In my initial discussion for modernizing Swift attributes (<a href="https://gist.github.com/erica/29c1a7fb7f49324d572f" class="">https://gist.github.com/erica/29c1a7fb7f49324d572f</a>), I wanted to eliminate snakecase from @warn-unused-result and `mutable_variant`. Of these, the second is a no-brainer. Instead of the non-standard argument label `mutable_variant`, use `mutableVariant`. Problem solved.</div><div class=""><br class=""></div><div class="">Converting `warn-unused-result` to the current standard of lowercase `warnunusedresult` produces a hard-to-read outcome. So in my write-up, I proposed the following amendments:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal; color: rgb(51, 51, 51);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@Autoclosure</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @autoclosure</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@Available</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @available</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@ObjC</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @objc</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@NoEscape</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @noescape</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@NonObjC</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @nonobjc</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@NoReturn</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @noreturn</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@Testable</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @testable</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@WarnUnusedResult</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @warn-unused-result</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@Convention</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @convention</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">@NoReturn</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// was @noreturn</span></pre><div class=""><br class=""></div></div><div class="">This was greeted somewhere between warmly and Siberian Winter depending on respondent. </div><div class=""><br class=""></div><div class=""><b class="">> Possible Approaches</b></div><div class=""><br class=""></div><div class="">After reading through Joe Groff's update to SE-0030, I'd like to push this again in a broader context (which is why I'm starting a new email thread). </div><div class=""><br class=""></div><div class="">* Is traditional namespacing the way to go? </div><div class="">* Could a simpler solution to upper camel all system-supplied attributes and lower camel all custom attributes be sufficient?</div><div class="">* Could any other "custom" decoration differentiate the two with easy parsing: for example @@lazy, @@delayed for custom and single-@ tokens for system supplied?</div><div class="">* Should I simply back off on modernizing warn-unused-result until SE-0030 is resolved?</div><div class=""><br class=""></div><div class="">What are your thoughts?</div></div></div></blockquote><br class=""></div><div class="">Once we open the floodgates for user-defined attributes, I think traditional namespacing and name lookup makes a lot of sense. We could conceptually namespace the existing hardcoded attributes into appropriate modules (Swift for the platform-neutral stuff, Foundation/AppKit/UIKit as appropriate for Appley stuff); name collisions would hopefully be rare enough that "@Swift.AutoClosure" or whatever hopefully won't often be necessary.</div><div class=""><br class=""></div><div class="">-Joe</div></div></div></blockquote></div><div class=""><br class=""></div>That would solve stuff. <div class=""><br class=""><div class="">How do you feel about my upcasing the attributes for readability?</div></div></div></div></blockquote><br class=""></div><div>Uppercasing seems reasonable to me.</div><div><br class=""></div><div>-Joe</div><br class=""></body></html>