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

[Jacob Bandes-Storch]

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> 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>
> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160217/4f6e4732/attachment.html>