[swift-evolution] [Further Discussion] Naming Attributes

[Erica Sadun]

> Here's a problem

* 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"

> 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.

> Modernization

In my initial discussion for modernizing Swift attributes (https://gist.github.com/erica/29c1a7fb7f49324d572f <https://gist.github.com/erica/29c1a7fb7f49324d572f>), 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.

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:

@Autoclosure // was @autoclosure
@Available // was @available
@ObjC // was @objc
@NoEscape // was @noescape
@NonObjC // was @nonobjc
@NoReturn // was @noreturn
@Testable // was @testable
@WarnUnusedResult // was @warn-unused-result
@Convention  // was @convention
@NoReturn // was @noreturn

This was greeted somewhere between warmly and Siberian Winter depending on respondent. 

> Possible Approaches

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). 

* Is traditional namespacing the way to go? 
* Could a simpler solution to upper camel all system-supplied attributes and lower camel all custom attributes be sufficient?
* Could any other "custom" decoration differentiate the two with easy parsing: for example @@lazy, @@delayed for custom and single-@ tokens for system supplied?
* Should I simply back off on modernizing warn-unused-result until SE-0030 is resolved?

What are your thoughts?

Thanks, -- Erica

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/f45efe72/attachment.html>