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

[Rudolf Adamkovic]

+1 for UpperCamelAttributes

R+

Sent from my iPhone

> On 18 Feb 2016, at 06:43, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> How would you re-design the existing upper camel attributes then?
> 
> They are: @UIApplicationMain, @NSManaged, @NSCopying, @NSApplicationMain, @IBAction, @IBDesignable, @IBInspectable, and @IBOutlet
> 
> -- E
> 
> 
>>> On Feb 17, 2016, at 10:29 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>>> 
>>> @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
>>> 
>>> In the revised design, the following example for Swift 2.2
>>> 
>>> @warn_unused_result(mutable_variant="sortInPlace")
>>> public func sort() -> [Self.Generator.Element]
>>> 
>>> becomes
>>> 
>>> @WarnUnusedResult(mutableVariant: "sortInPlace")
>>> public func sort() -> [Self.Generator.Element]
>> 
>> Wow, I'm surprised by how much I hate this. Currently, all Swift keywords are entirely lowercase (ignoring things like `Type`, `Protocol`, and `dynamicType` which come after a dot). I think I've learned to half-ignore things that look like that, but capitalizing suddenly pulls the spotlight onto these keywords. I'm just not a fan.
>> 
>> I think we're better off renaming or redesigning `warn_unused_result` so that it's readable when it's all-lowercase with no underscores. Some ideas:
>> 
>>    @onlyreturns func sorted() -> [Self.Generator.Element]
>>    func sorted() -> @important [Self.Generator.Element]
>> 
>> Alternatively, we could reverse the semantic and make all all non-Void functions warn unless they have an attribute saying not to.
>> 
>>    @ignoreresult mutating func updateValue(value: Value, forKey key: Key) -> Value?
>>    mutating func updateValue(value: Value, forKey key: Key) -> @ignorable Value?
>>    mutating func updateValue(value: Value, forKey key: Key) -> @convenience Value?
>> 
>> If we do that, we'll likely still want to be able to annotate non-mutating methods with their mutating variants (well, unless we think the compiler can guess based on the API Guidelines.)
>> 
>>    @variant(mutating: "sort") func sorted() -> [Self.Generator.Element]
>>    @alternative(mutating: "sort") func sorted() -> [Self.Generator.Element]
>> 
>> That opens the possibility of using `@variant(nonmutating:)` on mutating functions, too.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution