[swift-evolution] [Discussion] Modernizing Attribute Case and Attribute Argument Naming

Dany St-Amant dsa.mls at icloud.com
Wed Feb 17 21:27:10 CST 2016

> Le 17 févr. 2016 à 13:43, Erica Sadun via swift-evolution <swift-evolution at swift.org> a écrit :
> Do you have an alternative suggestion? I can add the following to the Alternatives Considered:
> Using lowercase for attributes names becomes confusing with longer compound examples. For example `warnunusedresult`
> looks a lot like a continuous string of lowercase characters. I recommend the Swift team consider introducing upper camel case
> for attributes to match the Cocoa members (UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, IBOutlet) or lower
> camel case to avoid this issue:
> @AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable, @WarnUnusedResult, @Convention, @NoReturn
> or
> @autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable, @warnUnusedResult, @convention, @noReturn

With a sticky-shift key/slow pinky, @UpperCaseCamel is easier to type than @lowerCaseCamel on many keyboards; but using any casing for these attributes give them higher visibility than what I think they might deserve. Those are only annotations and IMHO should not bring undue attention to themselves; writing them in all lowercase does achieve this goal. In a way, these can also be seen a little bit as the main language keywords, which are currently all lowercases (not sure if any multi-word keyword currently exist)

Yes, @warnunusedresult is a bit hard to read, but @noreturn is much more elegant than either @noReturn or @NoReturn. Even though, I suffer from slow pinky, I think I still prefer the all lowercase.

Since the only hard one to read in all lowercase is warnunusedresult, maybe this particular one could be renamed; @unusedresult(warn), still hard to read… @warn(unusedResult), this one look promising, but not sure how to cleanly combine with mutableVariant.

AFAIK, the @attibute will remain in full control of the compile, and never be open to user provided syntax. So (crazy thought), in a bold move (maybe a not so Swift like one) cases could be ignored, making everybody writing code happy, and everyone reading code of others unhappy.

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

More information about the swift-evolution mailing list