<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="">Hi Erica,<div class=""><br class=""></div><div class="">I’m sorry I’m late to the discussion (and I admit that I haven’t had time to follow it closely), but I have some concerns with your proposal in PR183.</div><div class=""><br class=""></div><div class="">Specifically, I think that working around a presumed attribute syntax for behaviors isn’t something worth worrying about at this point. Behaviors could go that way, or could go with a more behavior-specific syntax on the declaration site.</div><div class=""><br class=""></div><div class="">That said, user-defined attributes *are* something to anticipate. Here is a pile of assumptions which may or may not hold to be true, but I think are likely: I’d suspect that user defined attributes will be upper case (which fits better given that at least some of them will have to be explicitly module qualified). If we do this, we will rebrand the existing UIFoo and NSFoo ones as though they are user defined attributes, reverse justifying their uppercaseness. With this approach, the upper case namespace is for user defined stuff and the lower case namespace is for system stuff.</div><div class=""><br class=""></div><div class="">That style of approach would allow us to keep @autoclosure, @objc, @noreturn, @UIApplicationMain etc, while allowing users to define other new declaration attributes in the upper case namespace.</div><div class=""><br class=""></div><div class="">I agree that that leaves us with @warnunusedresult as an awkward suspect, but it is rarely used, and “when” we fix it to invert its polarity, it will hopefully be completely replaced.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 24, 2016, at 4:39 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Joshua,</div><div class=""><br class=""></div><div class="">Could you please peek at the latest version here: <a href="https://gist.github.com/erica/29c1a7fb7f49324d572f" class="">https://gist.github.com/erica/29c1a7fb7f49324d572f</a> Also, the [Further Discussion] Naming Attributes thread has subsumed this one.</div><div class=""><br class=""></div><div class="">Thanks, -- Erica</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 24, 2016, at 5:26 PM, Joshua Kopin via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="markdown"><p dir="auto" class="">+1</p><p dir="auto" class="">Jacob, I think your proposal is on point. Although I know this is probably outside the scope of what Erica would like to propose, I think it's important to point out that the custom attributes you called out arguably are so different semantically from the other attributes that they deserve their own syntactic treatment. Since the following analysis might affect the naming discussion, I'll put this out there now and see how it lands.</p><p dir="auto" class="">It seems to me that there are two broad categories of attributes, each of which wants its own level of syntactic optimization:</p>
<ul class="">
<li class=""><p dir="auto" class="">General Swift Attributes - use should be optimized</p>
<ul class="">
<li class="">Semantic Modifiers
<ul class="">
<li class=""><strong class="">@autoclosure</strong> / <strong class="">@autoclosure(escaping)</strong> - modifies expression semantics at call site</li>
<li class=""><strong class="">@convention(</strong>...<strong class="">)</strong> - modifies declared function's calling convention</li>
<li class=""><strong class="">@testable</strong> - modifies declaration's visibility</li>
<li class=""><strong class="">@noescape</strong> - modifies closure capture semantics, closure declaration syntax, escape analysis</li>
<li class=""><strong class="">@noreturn</strong> - modifies control flow analysis</li>
<li class=""><strong class="">@objc</strong> / <strong class="">@objc(</strong>...<strong class="">)</strong> / <strong class="">@nonobjc</strong> - modifies calling convention, class synthesis</li>
<li class=""><strong class="">@NSCopying</strong> - modifies property storage and semantics</li>
</ul></li>
<li class="">Warning and Error Generation Modifiers
<ul class="">
<li class=""><strong class="">@available(</strong><expression in the availability DSL><strong class="">)</strong></li>
<li class=""><strong class="">@warn_unused_result</strong></li>
<li class=""><strong class="">@warn_unused_result(message=</strong>...<strong class="">)</strong></li>
<li class=""><strong class="">@warn_unused_result(mutable_variant=</strong>...<strong class="">)</strong></li>
</ul></li>
</ul></li>
<li class=""><p dir="auto" class="">Specific Attributes - use should not be optimized</p>
<ul class="">
<li class="">Semantic Modifiers
<ul class="">
<li class=""><strong class="">@UIApplicationMain</strong> / <strong class="">@NSApplicationMain</strong> - specific to UIKit/AppKit</li>
<li class=""><strong class="">@NSManaged</strong> - specific to CoreData</li>
</ul></li>
<li class="">Xcode Semantic Modifiers
<ul class="">
<li class=""><strong class="">@IBAction</strong></li>
<li class=""><strong class="">@IBDesignable</strong></li>
<li class=""><strong class="">@IBInspectable</strong></li>
<li class=""><strong class="">@IBOutlet</strong></li>
</ul></li>
</ul></li>
</ul><p dir="auto" class="">(To be fair, @objc, @nonobjc, and @NSCopying are all tied to the Objective-C runtime and/or Foundation pretty closely and could arguably be considered framework-specific.)</p><p dir="auto" class="">As a first stab, how about something along the lines of the following?</p>
<ul class="">
<li class=""><p dir="auto" class="">General Swift Attributes</p>
<ul class="">
<li class="">Semantic Modifiers
<ul class="">
<li class=""><strong class="">@autoclosure</strong> / <strong class="">@autoclosure(escaping)</strong></li>
<li class=""><strong class="">@convention(</strong>...<strong class="">)</strong></li>
<li class=""><strong class="">@testable</strong></li>
<li class=""><strong class="">@noescape</strong></li>
<li class=""><strong class="">@noreturn</strong></li>
<li class=""><strong class="">@objc</strong> / <strong class="">@objc(</strong>...<strong class="">)</strong> / <strong class="">@nonbjc</strong></li>
<li class=""><strong class="">@copy</strong></li>
</ul></li>
<li class="">Warning and Error Generation Modifiers
<ul class="">
<li class=""><strong class="">@available(</strong><expression in the availability DSL><strong class="">)</strong></li>
<li class=""><strong class="">@warning(</strong><expression in a new warning DSL><strong class="">)</strong>
<ul class="">
<li class=""><strong class="">@warning(unusedResult)</strong></li>
<li class=""><strong class="">@warning(unusedResult, message=</strong>...<strong class="">)</strong></li>
<li class=""><strong class="">@warning(unusedResult, mutableVariant=</strong>...<strong class="">)</strong></li>
</ul></li>
</ul></li>
</ul></li>
<li class=""><p dir="auto" class="">Specific Attributes (syntax subject to bikeshedding)</p>
<ul class="">
<li class=""><strong class="">@modifyingCustomSemanticAttribute(</strong><expression in semantic attribute modifier DSL><strong class="">)</strong>
<ul class="">
<li class=""><strong class="">@modifyingCustomSemanticAttribute(Cocoa, applicationMain)</strong></li>
<li class=""><strong class="">@modifyingCustomSemanticAttribute(CoreData, managed)</strong></li>
<li class=""><strong class="">@modifyingCustomSemanticAttribute(InterfaceBuilder, action)</strong></li>
<li class=""><strong class="">@modifyingCustomSemanticAttribute(InterfaceBuilder, designable)</strong></li>
<li class=""><strong class="">@modifyingCustomSemanticAttribute(InterfaceBuilder, inspectable)</strong></li>
<li class=""><strong class="">@modifyingCustomSemanticAttribute(InterfaceBuilder, outlet)</strong></li>
</ul></li>
</ul></li>
</ul><p dir="auto" class="">On 17 Feb 2016, at 23:29, Jacob Bandes-Storch via swift-evolution wrote:</p>
<blockquote class=""><p dir="auto" class="">Arguably, these are all framework/IDE-specific functionality, a.k.a.<br class="">
"custom attributes", which should have an entirely different syntax.</p><p dir="auto" class="">On Wed, Feb 17, 2016 at 9:43 PM, Erica Sadun via swift-evolution <<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</p>
<blockquote class=""><p dir="auto" class="">How would you re-design the existing upper camel attributes then?</p><p dir="auto" class="">They are: @UIApplicationMain, @NSManaged, @NSCopying, @NSApplicationMain,<br class="">
@IBAction, @IBDesignable, @IBInspectable, and @IBOutlet</p><p dir="auto" class="">-- E</p>
<blockquote class=""><p dir="auto" class="">On Feb 17, 2016, at 10:29 PM, Brent Royal-Gordon <a href="mailto:brent@architechies.com" class="">brent@architechies.com</a></p>
</blockquote><p dir="auto" class="">wrote:</p>
<blockquote class="">
<blockquote class=""><p dir="auto" 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</p><p dir="auto" class="">In the revised design, the following example for Swift 2.2</p><p dir="auto" class="">@warn_unused_result(mutable_variant="sortInPlace")<br class="">
public func sort() -> [Self.Generator.Element]</p><p dir="auto" class="">becomes</p><p dir="auto" class="">@WarnUnusedResult(mutableVariant: "sortInPlace")<br class="">
public func sort() -> [Self.Generator.Element]</p>
</blockquote><p dir="auto" class="">Wow, I'm surprised by how much I hate this. Currently, all Swift</p>
</blockquote><p dir="auto" class="">keywords are entirely lowercase (ignoring things like <code class="">Type</code>, <code class="">Protocol</code>,<br class="">
and <code class="">dynamicType</code> which come after a dot). I think I've learned to<br class="">
half-ignore things that look like that, but capitalizing suddenly pulls the<br class="">
spotlight onto these keywords. I'm just not a fan.</p>
<blockquote class=""><p dir="auto" class="">I think we're better off renaming or redesigning <code class="">warn_unused_result</code> so</p>
</blockquote><p dir="auto" class="">that it's readable when it's all-lowercase with no underscores. Some ideas:</p>
<blockquote class="">
<pre class=""><code class=""> @onlyreturns func sorted() -> [Self.Generator.Element]
func sorted() -> @important [Self.Generator.Element]
</code></pre><p dir="auto" class="">Alternatively, we could reverse the semantic and make all all non-Void</p>
</blockquote><p dir="auto" class="">functions warn unless they have an attribute saying not to.</p>
<blockquote class="">
<pre class=""><code class=""> @ignoreresult mutating func updateValue(value: Value, forKey key:
</code></pre>
</blockquote><p dir="auto" class="">Key) -> Value?</p>
<blockquote class="">
<pre class=""><code class=""> mutating func updateValue(value: Value, forKey key: Key) ->
</code></pre>
</blockquote><p dir="auto" class="">@ignorable Value?</p>
<blockquote class="">
<pre class=""><code class=""> mutating func updateValue(value: Value, forKey key: Key) ->
</code></pre>
</blockquote><p dir="auto" class="">@convenience Value?</p>
<blockquote class=""><p dir="auto" class="">If we do that, we'll likely still want to be able to annotate</p>
</blockquote><p dir="auto" class="">non-mutating methods with their mutating variants (well, unless we think<br class="">
the compiler can guess based on the API Guidelines.)</p>
<blockquote class="">
<pre class=""><code class=""> @variant(mutating: "sort") func sorted() ->
</code></pre>
</blockquote><p dir="auto" class="">[Self.Generator.Element]</p>
<blockquote class="">
<pre class=""><code class=""> @alternative(mutating: "sort") func sorted() ->
</code></pre>
</blockquote><p dir="auto" class="">[Self.Generator.Element]</p>
<blockquote class=""><p dir="auto" class="">That opens the possibility of using <code class="">@variant(nonmutating:)</code> on mutating</p>
</blockquote><p dir="auto" class="">functions, too.</p>
<blockquote class=""><p dir="auto" class="">--<br class="">
Brent Royal-Gordon<br class="">
Architechies</p>
</blockquote>
<hr class=""><p dir="auto" 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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</blockquote>
<hr class=""><p dir="auto" 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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</blockquote>
</div>_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></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>