[Discussion] Modernizing Attribute Case and Attribute Argument Naming


(Erica Sadun) #1

For your consideration: Attribute Ophidiophobia. Feedback and suggestions welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD

<https://gist.github.com/erica/29c1a7fb7f49324d572f#introduction>Introduction

Two isolated instances of snake case remain in the Swift attribute grammar. This proposal updates those elements to bring them into compliance with modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the "[Discussion] Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to Michael Wells

<https://gist.github.com/erica/29c1a7fb7f49324d572f#motivation-and-detail-design>Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed warnunusedresult. The lower case pattern matches other compound attribute examples: autoclosure, objc, noescape, nonobjc, and noreturn.
The mutable_variant attribute argument should use lower camel case as is standard for native Swift argument labels and be renamed to mutableVariant.
Some non-native Swift attributes use a distinct pattern that does not apply to this proposal, specificallyUIApplicationMain, NSManaged, NSCopying, NSApplicationMain and do not fall under the scope of the native Swift lowercase convention.

<https://gist.github.com/erica/29c1a7fb7f49324d572f#alternatives-considered>Alternatives Considered

There are no alternatives for this proposal.


(Dmitri Gribenko) #2

Hi Erica,

Maybe it is just me, but I find @warnunusedresult to be unreadable --
it looks like a continuous string of lowercase characters at a glance.

Dmitri

···

On Wed, Feb 17, 2016 at 10:18 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions
welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun
Status: TBD
Review manager: TBD

Introduction

Two isolated instances of snake case remain in the Swift attribute grammar.
This proposal updates those elements to bring them into compliance with
modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the "[Discussion]
Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to
Michael Wells

Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that
no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed
warnunusedresult.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Erica Sadun) #3

Michael,

mutableVariant is an argument label, not an attribute name:

@warn_unused_result(message: "message", mutable_variant: "doThisThingInPlace")

becomes

@warnunusedresult(message: "message", mutableVariant: "doThisThingInPlace")

-- E

···

On Feb 17, 2016, at 11:26 AM, Michael Wells <michael@michaelwells.com> wrote:

Many thanks for writing this up. One nit-pick is mutableVariant should be mutablevariant.

I’m so happy that there are folks out there that care about these things. :slight_smile:

-mw

On Feb 17, 2016, at 10:18 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD

<https://gist.github.com/erica/29c1a7fb7f49324d572f#introduction>Introduction

Two isolated instances of snake case remain in the Swift attribute grammar. This proposal updates those elements to bring them into compliance with modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the "[Discussion] Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to Michael Wells

<https://gist.github.com/erica/29c1a7fb7f49324d572f#motivation-and-detail-design>Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed warnunusedresult. The lower case pattern matches other compound attribute examples: autoclosure, objc, noescape, nonobjc, and noreturn.
The mutable_variant attribute argument should use lower camel case as is standard for native Swift argument labels and be renamed to mutableVariant.
Some non-native Swift attributes use a distinct pattern that does not apply to this proposal, specificallyUIApplicationMain, NSManaged, NSCopying, NSApplicationMain and do not fall under the scope of the native Swift lowercase convention.

<https://gist.github.com/erica/29c1a7fb7f49324d572f#alternatives-considered>Alternatives Considered

There are no alternatives for this proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #4

Do you have an alternative suggestion? I can add the following to the Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer compound examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable, @WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable, @warnUnusedResult, @convention, @noReturn

-- E

···

On Feb 17, 2016, at 11:36 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Wed, Feb 17, 2016 at 10:18 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions
welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun
Status: TBD
Review manager: TBD

Introduction

Two isolated instances of snake case remain in the Swift attribute grammar.
This proposal updates those elements to bring them into compliance with
modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the "[Discussion]
Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to
Michael Wells

Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that
no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed
warnunusedresult.

Hi Erica,

Maybe it is just me, but I find @warnunusedresult to be unreadable --
it looks like a continuous string of lowercase characters at a glance.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>>*/


(Dmitri Gribenko) #5

Do you have an alternative suggestion?

I don't personally see an issue with using snake case for attributes
(they have a distinct namespace, so they can have their own naming
convention), but if the naming convention has to change, your
suggestions (quoted below) totally make sense to me.

Dmitri

···

On Wed, Feb 17, 2016 at 10:43 AM, Erica Sadun <erica@ericasadun.com> wrote:

I can add the following to the
Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer compound
examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend
the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged,
NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable,
IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable,
@WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable,
@warnUnusedResult, @convention, @noReturn

-- E

On Feb 17, 2016, at 11:36 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Wed, Feb 17, 2016 at 10:18 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions
welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun
Status: TBD
Review manager: TBD

Introduction

Two isolated instances of snake case remain in the Swift attribute grammar.
This proposal updates those elements to bring them into compliance with
modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the "[Discussion]
Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to
Michael Wells

Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that
no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed
warnunusedresult.

Hi Erica,

Maybe it is just me, but I find @warnunusedresult to be unreadable --
it looks like a continuous string of lowercase characters at a glance.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Erica Sadun) #6

No worries.

And I have updated the accompanying gist with a better example. Thank you.

https://gist.github.com/erica/29c1a7fb7f49324d572f

-- Erica

···

On Feb 17, 2016, at 11:33 AM, Michael Wells <michael@michaelwells.com> wrote:

Apologies. I didn’t read that very carefully.

-mw

On Feb 17, 2016, at 10:29 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

Michael,

mutableVariant is an argument label, not an attribute name:

@warn_unused_result(message: "message", mutable_variant: "doThisThingInPlace")

becomes

@warnunusedresult(message: "message", mutableVariant: "doThisThingInPlace")

-- E

On Feb 17, 2016, at 11:26 AM, Michael Wells <michael@michaelwells.com <mailto:michael@michaelwells.com>> wrote:

Many thanks for writing this up. One nit-pick is mutableVariant should be mutablevariant.

I’m so happy that there are folks out there that care about these things. :slight_smile:

-mw

On Feb 17, 2016, at 10:18 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD

<https://gist.github.com/erica/29c1a7fb7f49324d572f#introduction>Introduction

Two isolated instances of snake case remain in the Swift attribute grammar. This proposal updates those elements to bring them into compliance with modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the "[Discussion] Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to Michael Wells

<https://gist.github.com/erica/29c1a7fb7f49324d572f#motivation-and-detail-design>Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed warnunusedresult. The lower case pattern matches other compound attribute examples: autoclosure, objc, noescape, nonobjc, and noreturn.
The mutable_variant attribute argument should use lower camel case as is standard for native Swift argument labels and be renamed to mutableVariant.
Some non-native Swift attributes use a distinct pattern that does not apply to this proposal, specificallyUIApplicationMain, NSManaged, NSCopying, NSApplicationMain and do not fall under the scope of the native Swift lowercase convention.

<https://gist.github.com/erica/29c1a7fb7f49324d572f#alternatives-considered>Alternatives Considered

There are no alternatives for this proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Waite) #7

If you are taking votes, I would say lower camel case (since the attribute names are not types).

Visually I dislike @objC and @nonObjC, but there’s already a discussion ongoing about how to deal with abbreviations in names.

-DW

···

On Feb 17, 2016, at 11:43 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Do you have an alternative suggestion? I can add the following to the Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer compound examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable, @WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable, @warnUnusedResult, @convention, @noReturn

-- E

On Feb 17, 2016, at 11:36 AM, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:

On Wed, Feb 17, 2016 at 10:18 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions
welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun
Status: TBD
Review manager: TBD

Introduction

Two isolated instances of snake case remain in the Swift attribute grammar.
This proposal updates those elements to bring them into compliance with
modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the "[Discussion]
Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to
Michael Wells

Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that
no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed
warnunusedresult.

Hi Erica,

Maybe it is just me, but I find @warnunusedresult to be unreadable --
it looks like a continuous string of lowercase characters at a glance.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>>*/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Trent Nadeau) #8

I think both of the camel-case conventions are much easier to read, and
both are fine with me. I slightly prefer the former (UpperCamelCase), but
that just might be because the only languages I've used with annotations
that also have camel-case conventions (Java and C#) both use UpperCamelCase.

···

On Wed, Feb 17, 2016 at 1:43 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

Do you have an alternative suggestion? I can add the following to the
Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer
compound examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend
the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged,
NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable,
IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn,
@Testable, @WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn,
@testable, @warnUnusedResult, @convention, @noReturn

-- E

On Feb 17, 2016, at 11:36 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Wed, Feb 17, 2016 at 10:18 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions
welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun
Status: TBD
Review manager: TBD

Introduction

Two isolated instances of snake case remain in the Swift attribute grammar.
This proposal updates those elements to bring them into compliance with
modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the
"[Discussion]
Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip
to
Michael Wells

Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that
no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed
warnunusedresult.

Hi Erica,

Maybe it is just me, but I find @warnunusedresult to be unreadable --
it looks like a continuous string of lowercase characters at a glance.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Shawn Erickson) #9

"@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn,
@Testable, @WarnUnusedResult, @Convention, @NoReturn"

The above are much more readable to me and I believe most other humans :slight_smile:

I favor the UpperCamelCase style over the lowerCamelCase style for these.

-Shawn

···

On Wed, Feb 17, 2016 at 10:43 AM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

Do you have an alternative suggestion? I can add the following to the
Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer
compound examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend
the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged,
NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable,
IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn,
@Testable, @WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn,
@testable, @warnUnusedResult, @convention, @noReturn

-- E

On Feb 17, 2016, at 11:36 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Wed, Feb 17, 2016 at 10:18 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions
welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun
Status: TBD
Review manager: TBD

Introduction

Two isolated instances of snake case remain in the Swift attribute grammar.
This proposal updates those elements to bring them into compliance with
modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the
"[Discussion]
Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip
to
Michael Wells

Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that
no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed
warnunusedresult.

Hi Erica,

Maybe it is just me, but I find @warnunusedresult to be unreadable --
it looks like a continuous string of lowercase characters at a glance.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


#10

With a sticky-shift key/slow pinky, @UpperCaseCamel is easier to type than @lowerCaseCamel on many keyboards; but using any casing for these attributes give them higher visibility than what I think they might deserve. Those are only annotations and IMHO should not bring undue attention to themselves; writing them in all lowercase does achieve this goal. In a way, these can also be seen a little bit as the main language keywords, which are currently all lowercases (not sure if any multi-word keyword currently exist)

Yes, @warnunusedresult is a bit hard to read, but @noreturn is much more elegant than either @noReturn or @NoReturn. Even though, I suffer from slow pinky, I think I still prefer the all lowercase.

Since the only hard one to read in all lowercase is warnunusedresult, maybe this particular one could be renamed; @unusedresult(warn), still hard to read… @warn(unusedResult), this one look promising, but not sure how to cleanly combine with mutableVariant.

AFAIK, the @attibute will remain in full control of the compile, and never be open to user provided syntax. So (crazy thought), in a bold move (maybe a not so Swift like one) cases could be ignored, making everybody writing code happy, and everyone reading code of others unhappy.

Dany

···

Le 17 févr. 2016 à 13:43, Erica Sadun via swift-evolution <swift-evolution@swift.org> a écrit :

Do you have an alternative suggestion? I can add the following to the Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer compound examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable, @WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable, @warnUnusedResult, @convention, @noReturn


(Erica Sadun) #11

I think you guys have convinced me.

Re-jiggering.

-- E, who will be back with an updated version in a few minutes

···

On Feb 17, 2016, at 11:47 AM, Trent Nadeau <tanadeau@gmail.com> wrote:

I think both of the camel-case conventions are much easier to read, and both are fine with me. I slightly prefer the former (UpperCamelCase), but that just might be because the only languages I've used with annotations that also have camel-case conventions (Java and C#) both use UpperCamelCase.

On Wed, Feb 17, 2016 at 1:43 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Do you have an alternative suggestion? I can add the following to the Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer compound examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable, @WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable, @warnUnusedResult, @convention, @noReturn

-- E

On Feb 17, 2016, at 11:36 AM, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:

On Wed, Feb 17, 2016 at 10:18 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions
welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun
Status: TBD
Review manager: TBD

Introduction

Two isolated instances of snake case remain in the Swift attribute grammar.
This proposal updates those elements to bring them into compliance with
modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the "[Discussion]
Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to
Michael Wells

Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that
no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed
warnunusedresult.

Hi Erica,

Maybe it is just me, but I find @warnunusedresult to be unreadable --
it looks like a continuous string of lowercase characters at a glance.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>>*/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Erica Sadun) #12

Updated: https://gist.github.com/erica/29c1a7fb7f49324d572f

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
<https://gist.github.com/erica/29c1a7fb7f49324d572f#introduction>Introduction

Two isolated instances of snake case <https://en.wikipedia.org/wiki/Snake_case> remain in the Swift attribute grammar. This proposal updates those elements to bring them into compliance with modern Swift language standards and applies a new case pattern to existing attributes.

The Swift-Evolution discussion of this topic took place in the "[Discussion] Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to Michael Wells and Dmitri Gribenko

<https://gist.github.com/erica/29c1a7fb7f49324d572f#motivation-and-detail-design>Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that no longer match modern conventions, specifically the warn_unused_result attribute and the mutable_variant argument.

Updating the argument is easy. The mutable_variant attribute argument should use lower camel case as is standard for native Swift argument labels and be renamed mutableVariant.

If the warn_unused_result attribute is adjusted to the current lowercase convention, its renamed version becomes warnunusedresult. While this lower case pattern matches other compound attribute examples: objc, noescape, nonobjc, and noreturn, the re-engineered version of warnunusedresult looks like a continuous string of lowercase characters instead of punching clear, identifiable semantic elements. Using lowercase for complex attributes names, including future names yet to be introduced into the language becomes confusing when used with longer compound examples.

For this reason, I recommend the Swift team adopt an upper camel case convention for attributes to match the Cocoa members (UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, IBOutlet). This approach avoids the otherwise confusing long name issue and affects existing attributes as follows:

@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]
This revised example uses an argument colon (as proposed in "Replacing Equal Signs with Colons For Attribute Arguments") rather than the equal sign currently specified in Swift 2.2

<https://gist.github.com/erica/29c1a7fb7f49324d572f#alternatives-considered>Alternatives Considered

The team might prefer using lower camel case @autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable, @warnUnusedResult, @convention, @noReturn but this would be out of step with non-native Swift attributes, specifically UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, and IBOutlet

···

On Feb 17, 2016, at 11:50 AM, Shawn Erickson <shawnce@gmail.com> wrote:

"@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable, @WarnUnusedResult, @Convention, @NoReturn"

The above are much more readable to me and I believe most other humans :slight_smile:

I favor the UpperCamelCase style over the lowerCamelCase style for these.

-Shawn

On Wed, Feb 17, 2016 at 10:43 AM Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Do you have an alternative suggestion? I can add the following to the Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer compound examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable, @WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable, @warnUnusedResult, @convention, @noReturn

-- E


(Erica Sadun) #13

Agreed that Attribute names are not types but they have a precedent (as you see in the proposal here: https://gist.github.com/erica/29c1a7fb7f49324d572f) of upper camel among their items.

-- E

···

On Feb 17, 2016, at 12:35 PM, David Waite <david@alkaline-solutions.com> wrote:

If you are taking votes, I would say lower camel case (since the attribute names are not types).

Visually I dislike @objC and @nonObjC, but there’s already a discussion ongoing about how to deal with abbreviations in names.

-DW

On Feb 17, 2016, at 11:43 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Do you have an alternative suggestion? I can add the following to the Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer compound examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable, @WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable, @warnUnusedResult, @convention, @noReturn

-- E

On Feb 17, 2016, at 11:36 AM, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:

On Wed, Feb 17, 2016 at 10:18 AM, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

For your consideration: Attribute Ophidiophobia. Feedback and suggestions
welcome. -- Erica

Modernizing Attribute Case and Attribute Argument Naming

Proposal: TBD
Author(s): Erica Sadun
Status: TBD
Review manager: TBD

Introduction

Two isolated instances of snake case remain in the Swift attribute grammar.
This proposal updates those elements to bring them into compliance with
modern Swift language standards.

The Swift-Evolution discussion of this topic took place in the "[Discussion]
Modernizing Attribute Case and Attribute Argument Naming" thread. Hat tip to
Michael Wells

Motivation and Detail Design

Parts of the Swift attribute grammar retain lower snake case patterns that
no longer match modern conventions:

The warn_unused_result attribute should use lowercase and be renamed
warnunusedresult.

Hi Erica,

Maybe it is just me, but I find @warnunusedresult to be unreadable --
it looks like a continuous string of lowercase characters at a glance.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>>*/

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #14

I expect the core team to choose the approach they prefer. There is already precedent for upper camel, and no precedent for lower camel.

-- E

···

On Feb 17, 2016, at 8:27 PM, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

Le 17 févr. 2016 à 13:43, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Do you have an alternative suggestion? I can add the following to the Alternatives Considered:

Using lowercase for attributes names becomes confusing with longer compound examples. For example `warnunusedresult`
looks a lot like a continuous string of lowercase characters. I recommend the Swift team consider introducing upper camel case
for attributes to match the Cocoa members (UIApplicationMain, NSManaged, NSCopying, NSApplicationMain, IBAction, IBDesignable, IBInspectable, IBOutlet) or lower
camel case to avoid this issue:

@AutoClosure, @Available, @ObjC, @NoEscape, @NonObjC, @NoReturn, @Testable, @WarnUnusedResult, @Convention, @NoReturn

or

@autoClosure, @available, @objC, @noEscape, @nonObjC, @noReturn, @testable, @warnUnusedResult, @convention, @noReturn

With a sticky-shift key/slow pinky, @UpperCaseCamel is easier to type than @lowerCaseCamel on many keyboards; but using any casing for these attributes give them higher visibility than what I think they might deserve. Those are only annotations and IMHO should not bring undue attention to themselves; writing them in all lowercase does achieve this goal. In a way, these can also be seen a little bit as the main language keywords, which are currently all lowercases (not sure if any multi-word keyword currently exist)

Yes, @warnunusedresult is a bit hard to read, but @noreturn is much more elegant than either @noReturn or @NoReturn. Even though, I suffer from slow pinky, I think I still prefer the all lowercase.

Since the only hard one to read in all lowercase is warnunusedresult, maybe this particular one could be renamed; @unusedresult(warn), still hard to read… @warn(unusedResult), this one look promising, but not sure how to cleanly combine with mutableVariant.

AFAIK, the @attibute will remain in full control of the compile, and never be open to user provided syntax. So (crazy thought), in a bold move (maybe a not so Swift like one) cases could be ignored, making everybody writing code happy, and everyone reading code of others unhappy.

Dany
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brent Royal-Gordon) #15

@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


(Erica Sadun) #16

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@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


(Jacob Bandes-Storch) #17

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ondrej Barina) #18

+1 for first upper letter.
O.

···

On Feb 18, 2016 6:43 AM, "Erica Sadun via swift-evolution" < swift-evolution@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Rudolf Adamkovič) #19

+1 for UpperCamelAttributes

R+

···

Sent from my iPhone

On 18 Feb 2016, at 06:43, Erica Sadun via swift-evolution <swift-evolution@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Pierre Monod-Broca) #20

Arguably, these are all framework/IDE-specific functionality, a.k.a. "custom attributes", which should have an entirely different syntax.

+1

···

Le 18 févr. 2016 à 08:29, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> a écrit :

On Wed, Feb 17, 2016 at 9:43 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@architechies.com <mailto:brent@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution