[swift-evolution] [Further Discussion] Naming Attributes

[Eli Hini]

Erica and Joe,
Upcasing would be fine but are we going to combine it with traditional namespacing ? 

Eli 

> On Feb 19, 2016, at 13:17, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> On Feb 19, 2016, at 1:10 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>> 
>>> 
>>>> On Feb 19, 2016, at 2:04 PM, Joe Groff <jgroff at apple.com> wrote:
>>>> 
>>>> 
>>>> On Feb 19, 2016, at 12:17 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>>> 
>>>> > 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), 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?
>>> 
>>> 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.
>>> 
>>> -Joe
>> 
>> 
>> That would solve stuff. 
>> 
>> How do you feel about my upcasing the attributes for readability?
> 
> Uppercasing seems reasonable to me.
> 
> -Joe
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/5a56d432/attachment.html>