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

[Erica Sadun]

Joshua,

Could you please peek at the latest version here: https://gist.github.com/erica/29c1a7fb7f49324d572f  Also, the [Further Discussion] Naming Attributes thread has subsumed this one.

Thanks, -- Erica


> On Feb 24, 2016, at 5:26 PM, Joshua Kopin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +1
> 
> 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.
> 
> It seems to me that there are two broad categories of attributes, each of which wants its own level of syntactic optimization:
> 
> General Swift Attributes - use should be optimized
> 
> Semantic Modifiers
> @autoclosure / @autoclosure(escaping) - modifies expression semantics at call site
> @convention(...) - modifies declared function's calling convention
> @testable - modifies declaration's visibility
> @noescape - modifies closure capture semantics, closure declaration syntax, escape analysis
> @noreturn - modifies control flow analysis
> @objc / @objc(...) / @nonobjc - modifies calling convention, class synthesis
> @NSCopying - modifies property storage and semantics
> Warning and Error Generation Modifiers
> @available(<expression in the availability DSL>)
> @warn_unused_result
> @warn_unused_result(message=...)
> @warn_unused_result(mutable_variant=...)
> Specific Attributes - use should not be optimized
> 
> Semantic Modifiers
> @UIApplicationMain / @NSApplicationMain - specific to UIKit/AppKit
> @NSManaged - specific to CoreData
> Xcode Semantic Modifiers
> @IBAction
> @IBDesignable
> @IBInspectable
> @IBOutlet
> (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.)
> 
> As a first stab, how about something along the lines of the following?
> 
> General Swift Attributes
> 
> Semantic Modifiers
> @autoclosure / @autoclosure(escaping)
> @convention(...)
> @testable
> @noescape
> @noreturn
> @objc / @objc(...) / @nonbjc
> @copy
> Warning and Error Generation Modifiers
> @available(<expression in the availability DSL>)
> @warning(<expression in a new warning DSL>)
> @warning(unusedResult)
> @warning(unusedResult, message=...)
> @warning(unusedResult, mutableVariant=...)
> Specific Attributes (syntax subject to bikeshedding)
> 
> @modifyingCustomSemanticAttribute(<expression in semantic attribute modifier DSL>)
> @modifyingCustomSemanticAttribute(Cocoa, applicationMain)
> @modifyingCustomSemanticAttribute(CoreData, managed)
> @modifyingCustomSemanticAttribute(InterfaceBuilder, action)
> @modifyingCustomSemanticAttribute(InterfaceBuilder, designable)
> @modifyingCustomSemanticAttribute(InterfaceBuilder, inspectable)
> @modifyingCustomSemanticAttribute(InterfaceBuilder, outlet)
> On 17 Feb 2016, at 23:29, Jacob Bandes-Storch via swift-evolution wrote:
> 
> Arguably, these are all framework/IDE-specific functionality, a.k.a.
> "custom attributes", which should have an entirely different syntax.
> 
> On Wed, Feb 17, 2016 at 9:43 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>_______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160224/4304392f/attachment.html>