<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 18 févr. 2016 à 08:29, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Arguably, these are all framework/IDE-specific functionality, a.k.a. "custom attributes", which should have an entirely different syntax.</div></div></blockquote><div><br class=""></div>+1</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">
<br class=""><div class="gmail_quote">On Wed, Feb 17, 2016 at 9:43 PM, Erica Sadun via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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 class="">
<br class="">
They are: @UIApplicationMain, @NSManaged, @NSCopying, @NSApplicationMain, @IBAction, @IBDesignable, @IBInspectable, and @IBOutlet<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
-- E<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
<br class="">
> On Feb 17, 2016, at 10:29 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class="">
><br class="">
>> @Autoclosure // was @autoclosure<br class="">
>> @Available // was @available<br class="">
>> @ObjC // was @objc<br class="">
>> @NoEscape // was @noescape<br class="">
>> @NonObjC // was @nonobjc<br class="">
>> @NoReturn // was @noreturn<br class="">
>> @Testable // was @testable<br class="">
>> @WarnUnusedResult // was @warn-unused-result<br class="">
>> @Convention // was @convention<br class="">
>> @NoReturn // was @noreturn<br class="">
>><br class="">
>> In the revised design, the following example for Swift 2.2<br class="">
>><br class="">
>> @warn_unused_result(mutable_variant="sortInPlace")<br class="">
>> public func sort() -> [Self.Generator.Element]<br class="">
>><br class="">
>> becomes<br class="">
>><br class="">
>> @WarnUnusedResult(mutableVariant: "sortInPlace")<br class="">
>> public func sort() -> [Self.Generator.Element]<br class="">
><br class="">
> 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 class="">
><br class="">
> 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 class="">
><br class="">
> @onlyreturns func sorted() -> [Self.Generator.Element]<br class="">
> func sorted() -> @important [Self.Generator.Element]<br class="">
><br class="">
> Alternatively, we could reverse the semantic and make all all non-Void functions warn unless they have an attribute saying not to.<br class="">
><br class="">
> @ignoreresult mutating func updateValue(value: Value, forKey key: Key) -> Value?<br class="">
> mutating func updateValue(value: Value, forKey key: Key) -> @ignorable Value?<br class="">
> mutating func updateValue(value: Value, forKey key: Key) -> @convenience Value?<br class="">
><br class="">
> 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 class="">
><br class="">
> @variant(mutating: "sort") func sorted() -> [Self.Generator.Element]<br class="">
> @alternative(mutating: "sort") func sorted() -> [Self.Generator.Element]<br class="">
><br class="">
> That opens the possibility of using `@variant(nonmutating:)` on mutating functions, too.<br class="">
><br class="">
> --<br class="">
> Brent Royal-Gordon<br class="">
> Architechies<br class="">
><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>