<div dir="ltr">On Fri, Feb 19, 2016 at 1:05 PM Joe Groff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Feb 19, 2016, at 12:17 PM, Erica Sadun &lt;<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><div><b>&gt; Here&#39;s a problem</b></div><div><br></div>* There are Swift attributes: @autoclosure, @available, @objc, @noescape, @nonobjc, @noreturn, @testable, @warn-unused-result, @convention, @noreturn.<div>* There are ObjC-ish/Xcode-ish attributes: @UIApplicationMain, @NSManaged, @NSCopying, @NSApplicationMain, @IBAction, @IBDesignable, @IBInspectable, @IBOutlet</div><div>* 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>* The attribute syntax using `@` has had an intention &quot;to open the space up to user attributes at some point&quot;</div><div><br></div><div><b>&gt; Namespacing</b></div><div><br></div><div>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><br></div><div>`@Swift.autoclosure`, `@UIKit.UIApplicationMain`, `@UIKit.IBOutlet`, `@Swift.noreturn`, `@Custom.lazy`, etc.</div><div><br></div><div>Cumbersome, ugly, problematic.</div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div>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 &quot;@Swift.AutoClosure&quot; or whatever hopefully won&#39;t often be necessary.</div></div><div style="word-wrap:break-word"><div></div></div></blockquote><div><br></div><div> Yeah I agree but I personally struggling with how it will play out.<br></div><div><br></div><div>For example given attributes are often only valid in narrow semantic contexts. The compiler will enforce the semantics as needed of course and a human reading the code would likely understand the attribute in the context as written.</div><div><br></div><div>A human however may not easily understand the context in which a given attribute could be used especially if user defined ones start popping up. ...so is a naming methodology used to help, e.g. @Swift.PropertyBehaviour.lazy? or @MyStuff.PropertyBehaviour.extraLazy? ... however this quickly become overly verbose and likely ill-defined in naming, etc. Also it can duplicate what already can be understood from the usage context.</div><div><br></div><div>Sorry handing waving about this nothing clear to add on a way forward. It could imply contraction of problem domain to a more solvable one for a first iteration or two on this unless things are better understood in actually usage.</div><div><br></div><div>-Shawn</div><div><br></div></div></div>