[swift-evolution] [Further Discussion] Naming Attributes

[Brent Royal-Gordon]

> * There are Swift attributes: @autoclosure, @available, @objc, @noescape, @nonobjc, @noreturn, @testable, @warn-unused-result, @convention, @noreturn.
> * There are ObjC-ish/Xcode-ish attributes: @UIApplicationMain, @NSManaged, @NSCopying, @NSApplicationMain, @IBAction, @IBDesignable, @IBInspectable, @IBOutlet
> * 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.
> * The attribute syntax using `@` has had an intention "to open the space up to user attributes at some point"

I don't think this is a problem in and of itself. All the things that can come after an @ are attributes; behaviors allow you to declare your own attributes with a (small, but hopefully growing over time) subset of the full attribute semantics.

> > Namespacing
> 
> 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:
> 
> `@Swift.autoclosure`, `@UIKit.UIApplicationMain`, `@UIKit.IBOutlet`, `@Swift.noreturn`, `@Custom.lazy`, etc.
> 
> Cumbersome, ugly, problematic.

This *is* cumbersome and ugly, but so is `Foundation.NSArray`. You only fully qualify identifiers when the extra precision is necessary. Sure, it means you should try to give behaviors names that don't conflict with modules you're likely to work with (including the standard library), but this is already true of all Swift global symbols, including top-level type names. So I don't think this is problematic at all.

(Incidentally, I assume that `@Custom.lazy` comes from a module called "Custom", not that "Custom" is a prefix for all behaviors.)

-- 
Brent Royal-Gordon
Architechies