<p dir="ltr">+1 for first upper letter.<br>
O.</p>
<div class="gmail_quote">On Feb 18, 2016 6:43 AM, "Erica Sadun via swift-evolution" <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How would you re-design the existing upper camel attributes then?<br>
<br>
They are: @UIApplicationMain, @NSManaged, @NSCopying, @NSApplicationMain, @IBAction, @IBDesignable, @IBInspectable, and @IBOutlet<br>
<br>
-- E<br>
<br>
<br>
> On Feb 17, 2016, at 10:29 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br>
><br>
>> @Autoclosure // was @autoclosure<br>
>> @Available // was @available<br>
>> @ObjC // was @objc<br>
>> @NoEscape // was @noescape<br>
>> @NonObjC // was @nonobjc<br>
>> @NoReturn // was @noreturn<br>
>> @Testable // was @testable<br>
>> @WarnUnusedResult // was @warn-unused-result<br>
>> @Convention // was @convention<br>
>> @NoReturn // was @noreturn<br>
>><br>
>> In the revised design, the following example for Swift 2.2<br>
>><br>
>> @warn_unused_result(mutable_variant="sortInPlace")<br>
>> public func sort() -> [Self.Generator.Element]<br>
>><br>
>> becomes<br>
>><br>
>> @WarnUnusedResult(mutableVariant: "sortInPlace")<br>
>> public func sort() -> [Self.Generator.Element]<br>
><br>
> 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.<br>
><br>
> 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:<br>
><br>
> @onlyreturns func sorted() -> [Self.Generator.Element]<br>
> func sorted() -> @important [Self.Generator.Element]<br>
><br>
> Alternatively, we could reverse the semantic and make all all non-Void functions warn unless they have an attribute saying not to.<br>
><br>
> @ignoreresult mutating func updateValue(value: Value, forKey key: Key) -> Value?<br>
> mutating func updateValue(value: Value, forKey key: Key) -> @ignorable Value?<br>
> mutating func updateValue(value: Value, forKey key: Key) -> @convenience Value?<br>
><br>
> 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.)<br>
><br>
> @variant(mutating: "sort") func sorted() -> [Self.Generator.Element]<br>
> @alternative(mutating: "sort") func sorted() -> [Self.Generator.Element]<br>
><br>
> That opens the possibility of using `@variant(nonmutating:)` on mutating functions, too.<br>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>