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

Tue Mar 1 22:04:15 CST 2016

Hi Erica,

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.

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.

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.

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.

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.

-Chris

> On Feb 24, 2016, at 4:39 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Joshua,
> 
> Could you please peek at the latest version here: https://gist.github.com/erica/29c1a7fb7f49324d572f <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 <mailto: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 <mailto:swift-evolution at swift.org>
>> 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/20160301/40370b43/attachment.html>