RFC: didset and willset

Evolution Discussion
41

I may be wrong but I don't remember any other case of a keyword in
Swift composed of two or more words, so I believe these should be
exceptions.

`typealias` and `associatedtype` are the main examples; there were huge catfights on swift-evolution about whether the latter should be `associatedtype`, `associatedType`, or `associated_type`. There are also a number of attributes like `@noescape` and `@discardableResult`, which aren't 100% consistent.

Right, but the catfight had a clear outcome:

1) keywords are conjoined
2) attributes are lower camel cased.
3) attributes should use “non” not “no”. noescape should be nonescaping (and thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features? I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left). They will raise different sorts of discussion, even though they both seem obvious to me.

Fair enough. It just feels like it makes it more difficult to reach consistency that way (the discussions could have different outcomes) and consistency is the whole motivation behind these proposals.

···

On May 20, 2016, at 12:39 PM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 7:24 AM, Matthew Johnson <matthew@anandabits.com> wrote:

On May 20, 2016, at 1:11 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

-Chris

42

When we introduce property behaviors, the surface level syntax for this sort of thing is likely to remain the same, and it therefore stands to reason that the behavior “accessors” would follow the same convention as keywords.

Yes, but what will the conventions be? Is the accessor for the "did change" behavior going to be `didchange` or `didChange`?

I’m arguing for “didchange”.

To be clear, this is just my personal opinion, but even in the context of a general user-defined behavior, these things seem extremely "keyword like” from the users perspective. To a user of a behavior, these aspects are not arbitrary user defined names, they are specific things that you can pick from. The existing accessors clearly work the same way.

If I write a JSON behavior, is my accessor going to be `toJSON` or `tojson`?

If you’re writing a JSON behavior, including “JSON” in the accessor would be a needless word. The names for the accessors should describe “aspects” of the behavior they are implementing, not the behavior itself.

That said, you’re right that this could come up. When and if we have a specific example to discuss, I'm sure we can figure out a reasonable policy.

*That*—not some general rule about keywords which is primarily designed to address things like `fallthrough` and `associatedtype`—is what I think `willSet` and `didSet` ought to match. Users do not care whether something comes out of the standard library or the language grammar; they care whether it has the feel of other things which fit that syntactic slot.

I don’t understand what you’re trying to say here.

(For instance, a perhaps controversial opinion: I think `dynamicType` is properly capitalized for the syntactic
slot it's in.

As I mentioned down-thread, the problem with .dynamicType is that it is in the wrong slot :-)

Thus, `willSet` and `didSet` should be capitalized like other, user-defined, accessors.

I agree with your believe that we should treat these just like user-defined accessors. So lets assume we had an “observed” behavior that had didset/willset aspects that can be specified. To the implementor of the behavior, these are terms that they define, but to users of the behavior, they are indistinguishable from keywords.

So you’re arguing that all user-defined accessors in all user-defined behaviors should be all lowercase? Are we sure that there would be no legitimate accessor names which would be very hard to read without some kind of visible word boundaries?

···

On May 20, 2016, at 12:50 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 19, 2016, at 11:34 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

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

43

If accessors are defined by the developer who designs a property behavior then I do not see them as keywords. Or am I wrong?

That is why I would prefer them lowerCamelCase.

···

On May 20, 2016, at 1:50 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Thus, `willSet` and `didSet` should be capitalized like other, user-defined, accessors.

I agree with your believe that we should treat these just like user-defined accessors. So lets assume we had an “observed” behavior that had didset/willset aspects that can be specified. To the implementor of the behavior, these are terms that they define, but to users of the behavior, they are indistinguishable from keywords.

44

I think that these are the relevant rules. As I mentioned upthread, .dynamicType is broken for a different reason, and thus leads to a different solution (it should be a global function in the stdlib, not a propery).

-Chris

···

On May 20, 2016, at 10:41 AM, Erica Sadun <erica@ericasadun.com> wrote:

Right, but the catfight had a clear outcome:

1) keywords are conjoined
2) attributes are lower camel cased.
3) attributes should use “non” not “no”. noescape should be nonescaping (and thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features? I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left). They will raise different sorts of discussion, even though they both seem obvious to me.

Before putting together a proposal, are there any other de-facto rules besides the three already listed that touch on naming keywords and attributes? (I suppose no snake case is a given)

45

Separate action items:

* Move dynamicType to standard library as a global function
* Rename didSet and willSet to lowercase to conform to Swift standard of conjoined lowercase keywords.
* Rename noescape to nonescaping to conform to Swift standard of "non"-modified attributes

Roger that?

-- E

···

On May 20, 2016, at 11:43 AM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 10:41 AM, Erica Sadun <erica@ericasadun.com> wrote:

Right, but the catfight had a clear outcome:

1) keywords are conjoined
2) attributes are lower camel cased.
3) attributes should use “non” not “no”. noescape should be nonescaping (and thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features? I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left). They will raise different sorts of discussion, even though they both seem obvious to me.

Before putting together a proposal, are there any other de-facto rules besides the three already listed that touch on naming keywords and attributes? (I suppose no snake case is a given)

I think that these are the relevant rules. As I mentioned upthread, .dynamicType is broken for a different reason, and thus leads to a different solution (it should be a global function in the stdlib, not a propery).

-Chris

46

(For instance, a perhaps controversial opinion: I think `dynamicType` is properly capitalized for the syntactic slot it's in. That's not to say I think we should *keep* `dynamicType`, but simply that `foo.dynamicType` is more appropriate than `foo.dynamictype` would be.)

+1. 'foo.dynamictype' seems strange to me.

foo.dynamicType is broken for other reasons. I see x.dynamicType as being a named operator (like sizeof) and not a property. For example, we don’t want .dynamicType to show up in code completion on every value in the universe ("4.dynamicType”, really?).

That argues that it should be spelled as dynamicType(x), and ideally being a standard library feature instead of a keyword.

That makes sense. It never crossed my mind until now, but given that `sizeof` is a standard library feature why isn’t it camel case `sizeOf`? Is this a case of “term of the art”?

···

On May 20, 2016, at 12:41 PM, Chris Lattner <clattner@apple.com> wrote:
On May 20, 2016, at 7:26 AM, Matthew Johnson <matthew@anandabits.com> wrote:

-Chris

47

Gist: dynamicType.md · GitHub

Moving dynamicType to the standard library

Proposal: TBD
Author: Erica Sadun <https://github.com/erica&gt;
Status: TBD
Review manager: TBD
<dynamicType.md · GitHub

This proposal establishes dynamicType as a named operator rather than a property and moves it to the standard library.

<dynamicType.md · GitHub

In Swift, dynamicType is a property. Because of that, it shows up in code completion as an "appropriate" completion for all values, regardless of whether it makes sense to do so or not. For example, Swift offers 4.dynamicType, myFunction().dynamicType, etc. Rather than express a logical attribute of a specific type, it can be applied to any expression. Since dynamicType behaves more like a operator (like sizeof), its implementation should follow suit.

Moving it to the standard library, allows Swift to remove a keyword and better aligns the functionality with its intended use.

<dynamicType.md · GitHub Design

Upon adoption of this proposal, Swift removes the dynamicType keyword and introduces a dynamicType function:

dynamicType(value) // returns the dynamicType of value
<dynamicType.md · GitHub on Existing Code

Adopting this proposal will break code and require migration support, moving the postfix property syntax into a prefix function call.

<dynamicType.md · GitHub Considered

Not adopting this proposal

···

On May 20, 2016, at 11:41 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 20, 2016, at 7:26 AM, Matthew Johnson <matthew@anandabits.com> wrote:

(For instance, a perhaps controversial opinion: I think `dynamicType` is properly capitalized for the syntactic slot it's in. That's not to say I think we should *keep* `dynamicType`, but simply that `foo.dynamicType` is more appropriate than `foo.dynamictype` would be.)

+1. 'foo.dynamictype' seems strange to me.

foo.dynamicType is broken for other reasons. I see x.dynamicType as being a named operator (like sizeof) and not a property. For example, we don’t want .dynamicType to show up in code completion on every value in the universe ("4.dynamicType”, really?).

That argues that it should be spelled as dynamicType(x), and ideally being a standard library feature instead of a keyword.

-Chris

48

I agree with you completely. I tried to argue the same thing but maybe not as eloquently :P.

I don't think the qualification should be that all keywords must look a specific way but more like "where does this fit in naturally".

dynamicType is masquerading as a property and didSet and willSet are acting like methods and I think they should look as such unless they are changed.

Brandon

···

On May 20, 2016, at 4:02 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

When we introduce property behaviors, the surface level syntax for this sort of thing is likely to remain the same, and it therefore stands to reason that the behavior “accessors” would follow the same convention as keywords.

Yes, but what will the conventions be? Is the accessor for the "did change" behavior going to be `didchange` or `didChange`?

I’m arguing for “didchange”.

To be clear, this is just my personal opinion, but even in the context of a general user-defined behavior, these things seem extremely "keyword like” from the users perspective. To a user of a behavior, these aspects are not arbitrary user defined names, they are specific things that you can pick from. The existing accessors clearly work the same way.

Okay. That was not the answer I expected :^), but if that is your answer, and if you're pretty confident in that answer, then I support changing willSet and didSet.

*That*—not some general rule about keywords which is primarily designed to address things like `fallthrough` and `associatedtype`—is what I think `willSet` and `didSet` ought to match. Users do not care whether something comes out of the standard library or the language grammar; they care whether it has the feel of other things which fit that syntactic slot.

I don’t understand what you’re trying to say here.

I'm trying to articulate a general rule, that when there is a built-in thing that goes alongside user-defined things, the built-in thing should be capitalized like the user-defined things even if it's implemented as a "keyword".

That is, nobody cares whether dynamicType is a keyword or an extension on Any, and nobody cares whether willSet is a keyword or an accessor for a built-in property. Since they behave like something else in the grammar, they should be spelled like that thing, too.

(For instance, a perhaps controversial opinion: I think `dynamicType` is properly capitalized for the syntactic
slot it's in.

As I mentioned down-thread, the problem with .dynamicType is that it is in the wrong slot :-)

I don't necessarily disagree. What I'm saying is, fake properties should be capitalized like real properties, and fake accessors should be capitalized like real accessors.

--
Brent Royal-Gordon
Architechies

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

49

Yes, I don’t think they are the same as keywords, and should stay camelCase. Especially if you can define your own with behaviours — it will feel like you are defining your own keywords, which is wrong.

userDefined
languagedefined

I’d much prefer to just stay with willSet and didSet. Let’s see what behaviours turn out to be, and design some pinned down rules then.

As Erica said in her post about Swift 3, "Make big breaking changes later and once rather than sooner and multiple times.”

Chris said "In practice, we can accept both spellings for a long time at no harm to anyone.”, so hopefully as proposed Swift 3 would support both willSet/didSet & willset/didset anyway. So this is a pointless addition with wishes for consistency that won’t be known until property behaviours.

The other proposals for dynamicType etc sound fine to me.

···

On 21 May 2016, at 11:03 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

If accessors are defined by the developer who designs a property behavior then I do not see them as keywords. Or am I wrong?

That is why I would prefer them lowerCamelCase.

On May 20, 2016, at 1:50 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Thus, `willSet` and `didSet` should be capitalized like other, user-defined, accessors.

I agree with your believe that we should treat these just like user-defined accessors. So lets assume we had an “observed” behavior that had didset/willset aspects that can be specified. To the implementor of the behavior, these are terms that they define, but to users of the behavior, they are indistinguishable from keywords.

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

50

Right, but the catfight had a clear outcome:

1) keywords are conjoined
2) attributes are lower camel cased.
3) attributes should use “non” not “no”. noescape should be nonescaping (and thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features? I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left). They will raise different sorts of discussion, even though they both seem obvious to me.

Before putting together a proposal, are there any other de-facto rules besides the three already listed that touch on naming keywords and attributes? (I suppose no snake case is a given)

I think that these are the relevant rules. As I mentioned upthread, .dynamicType is broken for a different reason, and thus leads to a different solution (it should be a global function in the stdlib, not a propery).

-Chris

Separate action items:

* Move dynamicType to standard library as a global function
* Rename didSet and willSet to lowercase to conform to Swift standard of conjoined lowercase keywords.

Sounds great.

* Rename noescape to nonescaping to conform to Swift standard of "non"-modified attributes

I just looked and the one other wrong one we have is “noreturn”. It would be great to tackle nonescaping and whatever noreturn should be in the same proposal.

Thanks Erica!

-Chris

···

On May 20, 2016, at 10:48 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 20, 2016, at 11:43 AM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 10:41 AM, Erica Sadun <erica@ericasadun.com> wrote:

51

To be clear before I put anything together, `nonreturning`, yes?

-- E

···

On May 20, 2016, at 11:52 AM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 10:48 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 20, 2016, at 11:43 AM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 10:41 AM, Erica Sadun <erica@ericasadun.com> wrote:

Right, but the catfight had a clear outcome:

1) keywords are conjoined
2) attributes are lower camel cased.
3) attributes should use “non” not “no”. noescape should be nonescaping (and thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features? I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left). They will raise different sorts of discussion, even though they both seem obvious to me.

Before putting together a proposal, are there any other de-facto rules besides the three already listed that touch on naming keywords and attributes? (I suppose no snake case is a given)

I think that these are the relevant rules. As I mentioned upthread, .dynamicType is broken for a different reason, and thus leads to a different solution (it should be a global function in the stdlib, not a propery).

-Chris

Separate action items:

* Move dynamicType to standard library as a global function
* Rename didSet and willSet to lowercase to conform to Swift standard of conjoined lowercase keywords.

Sounds great.

* Rename noescape to nonescaping to conform to Swift standard of "non"-modified attributes

I just looked and the one other wrong one we have is “noreturn”. It would be great to tackle nonescaping and whatever noreturn should be in the same proposal.

Thanks Erica!

-Chris

52

>
>>> (For instance, a perhaps controversial opinion: I think `dynamicType`
is properly capitalized for the syntactic slot it's in. That's not to say I
think we should *keep* `dynamicType`, but simply that `foo.dynamicType` is
more appropriate than `foo.dynamictype` would be.)
>>
>> +1. 'foo.dynamictype' seems strange to me.
>
> foo.dynamicType is broken for other reasons. I see x.dynamicType as
being a named operator (like sizeof) and not a property. For example, we
don’t want .dynamicType to show up in code completion on every value in the
universe ("4.dynamicType”, really?).
>
> That argues that it should be spelled as dynamicType(x), and ideally
being a standard library feature instead of a keyword.

That makes sense. It never crossed my mind until now, but given that
`sizeof` is a standard library feature why isn’t it camel case `sizeOf`?
Is this a case of “term of the art”?

See: http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830/

···

On Fri, May 20, 2016 at 1:16 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

> On May 20, 2016, at 12:41 PM, Chris Lattner <clattner@apple.com> wrote:
> On May 20, 2016, at 7:26 AM, Matthew Johnson <matthew@anandabits.com> > wrote:

>
> -Chris

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

53

Please look through and comment:

Gist contents pasted below.

-- Erica

Adopting consistent keyword casing in Swift

Proposal: TBD
Author: Erica Sadun <https://github.com/erica&gt;
Status: TBD
Review manager: TBD
<didset.md · GitHub

This proposal adopts consistent conjoined keyword lowercasing.

Swift-evolution thread: RFC: didset and willset <http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534&gt;
<didset.md · GitHub

Swift is an opinionated language. One opinion it adheres to is that keywords should use conjoined lowercasing. Conjoined lowercase terms already in the language include typealias, associatedtype, and fallthrough. Using this casing style enables programmers to treat keywords as atomic concepts. This proposal formalizes this rule and fixes current inconsistencies.

<didset.md · GitHub Casing Rules Roadmap

This proposal addresses the first of the following Swift casing rules:

Keywords use lower case conjoined naming.
Attributes use lower camel cased naming.
Attributes use “non” prefixes in preference to "no" prefixes.
Compiler-expanded literals use lower camel casing and are prefixed with octothorpes (#)
Swift eschews snake casing. (See also: SE-0028 <https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md&gt;\)
Terms of art may be exempted from casing rules.
Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. @UIApplicationMain.
<didset.md · GitHub Language Cleanup Roadmap

This proposal is part of a series that will:

Normalize casing to lower conjoined names.
Normalize naming for "negative" attributes (from "noFeature" to "nonfeaturing").
Move dynamicType to the standard library as a global function.
<didset.md · GitHub Design

Upon adoption, Swift will rename didSet and willSet to willset and didset. Future expansions to the language will follow this adopted rule, for example didchange.

This proposal deliberately omits the dynamicType keyword, which will be addressed under separate cover: to be moved to the standard library as a standalone global function.

<didset.md · GitHub on Existing Code

This proposal requires migration support to rename keywords that use the old convention to adopt the new convention. This is a simple substitution that should limit effect on code.

This proposal recommends deprecating old-style keywords in Swift 2.3 and removing them in Swift 3.

<didset.md · GitHub Considered

Not adopting this rule for Swift.

···

On May 20, 2016, at 11:52 AM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 10:48 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 20, 2016, at 11:43 AM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 10:41 AM, Erica Sadun <erica@ericasadun.com> wrote:

Right, but the catfight had a clear outcome:

1) keywords are conjoined
2) attributes are lower camel cased.
3) attributes should use “non” not “no”. noescape should be nonescaping (and thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features? I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left). They will raise different sorts of discussion, even though they both seem obvious to me.

Before putting together a proposal, are there any other de-facto rules besides the three already listed that touch on naming keywords and attributes? (I suppose no snake case is a given)

I think that these are the relevant rules. As I mentioned upthread, .dynamicType is broken for a different reason, and thus leads to a different solution (it should be a global function in the stdlib, not a propery).

-Chris

Separate action items:

* Move dynamicType to standard library as a global function
* Rename didSet and willSet to lowercase to conform to Swift standard of conjoined lowercase keywords.

Sounds great.

* Rename noescape to nonescaping to conform to Swift standard of "non"-modified attributes

I just looked and the one other wrong one we have is “noreturn”. It would be great to tackle nonescaping and whatever noreturn should be in the same proposal.

Thanks Erica!

-Chris

54

Part 2: negative.md · GitHub

Gist pasted below

Normalizing naming for "negative" attributes

Proposal: TBD
Author: Erica Sadun <https://github.com/erica&gt;
Status: TBD
Review manager: TBD
<negative.md · GitHub

This proposal normalizes naming for "negative" attributes by adopting a rule that replaces camel-cased property names starting with no with adjectives starting with non.

Swift-evolution thread: RFC: didset and willset <http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534&gt;
<negative.md · GitHub

Some Swift-sourced attributes including available and testable are both adjectives. Converting no-prefixed attributes to non changes them into a single word that describes how they modify the syntax they decorate.

<negative.md · GitHub Casing Rules Roadmap

This proposal addresses the third of the following Swift casing rules:

Keywords use lower case conjoined naming.
Attributes use lower camel cased naming.
Attributes use “non” prefixes in preference to "no" prefixes.
Compiler-expanded literals use lower camel casing and are prefixed with octothorpes (#)
Swift eschews snake casing. (See also: SE-0028 <https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md&gt;\)
Terms of art may be exempted from casing rules.
Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. @UIApplicationMain.
Keywords that appear in the same syntactic locations as user-defined names should follow the convention of those user-defined names.
<negative.md · GitHub Language Cleanup Roadmap

This proposal is part of a series that will:

Normalize casing to lower conjoined names.
Normalize naming for "negative" attributes (from "noFeature" to "nonfeaturing").
Move dynamicType to the standard library as a global function.
<negative.md · GitHub Design

Upon adoption, Swift will rename:

noreturn to nonreturning
noescape to nonescaping
<negative.md · GitHub on Existing Code

This proposal requires migration support to rename keywords that use the old convention to adopt the new convention. This is a simple substitution that should limit effect on code.

<negative.md · GitHub Considered

The core team may consider exceptions for terms of art. For example, "no return" indicates "there is no return from this function", as in the "point of no return".

···

On May 20, 2016, at 11:52 AM, Chris Lattner <clattner@apple.com> wrote:
On May 20, 2016, at 10:48 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 20, 2016, at 11:43 AM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 10:41 AM, Erica Sadun <erica@ericasadun.com> wrote:

Right, but the catfight had a clear outcome:

1) keywords are conjoined
2) attributes are lower camel cased.
3) attributes should use “non” not “no”. noescape should be nonescaping (and thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features? I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left). They will raise different sorts of discussion, even though they both seem obvious to me.

Before putting together a proposal, are there any other de-facto rules besides the three already listed that touch on naming keywords and attributes? (I suppose no snake case is a given)

I think that these are the relevant rules. As I mentioned upthread, .dynamicType is broken for a different reason, and thus leads to a different solution (it should be a global function in the stdlib, not a propery).

-Chris

Separate action items:

* Move dynamicType to standard library as a global function
* Rename didSet and willSet to lowercase to conform to Swift standard of conjoined lowercase keywords.
* Rename noescape to nonescaping to conform to Swift standard of "non"-modified attributes

Sounds great.

55

Upon adoption, Swift will rename didSet and willSet to willset and didset. Future expansions to the language will follow this adopted rule, for example didchange.

Might want to switch the order of the two keywords in one of those pairs, unless you're proposing we prank our user base. :^)

···

--
Brent Royal-Gordon
Architechies

56

>
>>> (For instance, a perhaps controversial opinion: I think `dynamicType` is properly capitalized for the syntactic slot it's in. That's not to say I think we should *keep* `dynamicType`, but simply that `foo.dynamicType` is more appropriate than `foo.dynamictype` would be.)
>>
>> +1. 'foo.dynamictype' seems strange to me.
>
> foo.dynamicType is broken for other reasons. I see x.dynamicType as being a named operator (like sizeof) and not a property. For example, we don’t want .dynamicType to show up in code completion on every value in the universe ("4.dynamicType”, really?).
>
> That argues that it should be spelled as dynamicType(x), and ideally being a standard library feature instead of a keyword.

That makes sense. It never crossed my mind until now, but given that `sizeof` is a standard library feature why isn’t it camel case `sizeOf`? Is this a case of “term of the art”?

See: http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830/

Thanks. That’s what I figured. :)

···

On May 20, 2016, at 1:30 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Fri, May 20, 2016 at 1:16 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> On May 20, 2016, at 12:41 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
> On May 20, 2016, at 7:26 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

>
> -Chris

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

57

Swift Casing Rules Roadmap

This proposal addresses the first of the following Swift casing rules:

  • Keywords use lower case conjoined naming.
  • Attributes use lower camel cased naming.
  • Attributes use “non” prefixes in preference to "no" prefixes.
  • Compiler-expanded literals use lower camel casing and are prefixed with octothorpes (#)
  • Swift eschews snake casing. (See also: SE-0028)
  • Terms of art may be exempted from casing rules.
  • Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. @UIApplicationMain.

I started working on expanding this and ended up creating a general set of guidelines for naming language entities in Swift. Oops. You might want to just use the relevant subset.

* * *

Keywords:

1. Appear anywhere in the grammar appropriate for their purpose.
2. Have no prefix.
3. Use lowercaseonly naming (conjoined without underscores) and have no prefix.
4. May be any part of speech appropriate for the use, but are usually nouns, verbs, conjunctions, or prepositions, rarely adjectives or adverbs.

Declaration modifiers:

1. Appear in declarations before the declaration's keyword (e.g. `let`, `func`), or before the type if there is no keyword (e.g. function parameters). Can be intermixed with attributes.
2. Have no prefix.
3. Use lowercaseonly naming (conjoined without underscores) and have no prefix.
4. Are usually adjectives.

Attributes:

1. Appear in declarations before the declaration's keyword (e.g. `let`, `func`), or before the type if there is no keyword (e.g. function parameters). Can be intermixed with declaration modifiers.
2. Are prefixed with `@` symbols.
3. Use lowerCamelCase, unless prefixed to match a closely related module, in which case they use PFXUpperCamelCase.
  * Prefixes like "auto" and "non" do not introduce new words.
4. Are usually adjectives or involve an adjective.
  * When constructing an attribute name from a verb, use the "-ing" form (e.g. "escaping", not "escape") to turn it into an adjective.
  * When negating a term, use the "non" prefix.

Build configuration statements:

1. Appear where statements or declarations are valid.
2. Are prefixed with `#` symbols.
3. Use lowercaseonly naming (conjoined without underscores) and have no prefix.
  * If block-scoped, they run until a matching `#end<foo>` statement.
4. May be any part of speech appropriate for the use, but are usually verbs, conjunctions, or prepositions.

Compiler-expanded expressions:
  
1. Are prefixed with `#` symbols.
2. Use lowerCamelCase, unless prefixed to match a closely related module, in which case they use PFXUpperCamelCase.
3. Are usually nouns, but may be adjectives if they have parameters and are testing for that trait.[1]
4. Appear in expressions.

As always in Swift naming, you may deviate from these rules to preserve a widely-used term of art if it is a very close match for the meaning of the entity.

[1] The adjective rule here is for #available. Should that be #isAvailable, though? That would more closely match our usual rules about Boolean expressions.

···

--
Brent Royal-Gordon
Architechies

58

Fixing

-- E

···

On May 20, 2016, at 2:48 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

Upon adoption, Swift will rename didSet and willSet to willset and didset. Future expansions to the language will follow this adopted rule, for example didchange.

Might want to switch the order of the two keywords in one of those pairs, unless you're proposing we prank our user base. :^)

--
Brent Royal-Gordon
Architechies

59

Right, but the catfight had a clear outcome:

1) keywords are conjoined
2) attributes are lower camel cased.
3) attributes should use “non” not “no”. noescape should be nonescaping (and thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features? I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left). They will raise different sorts of discussion, even though they both seem obvious to me.

Before putting together a proposal, are there any other de-facto rules besides the three already listed that touch on naming keywords and attributes? (I suppose no snake case is a given)

I think that these are the relevant rules. As I mentioned upthread, .dynamicType is broken for a different reason, and thus leads to a different solution (it should be a global function in the stdlib, not a propery).

-Chris

Separate action items:

* Move dynamicType to standard library as a global function
* Rename didSet and willSet to lowercase to conform to Swift standard of conjoined lowercase keywords.

Sounds great.

* Rename noescape to nonescaping to conform to Swift standard of "non"-modified attributes

I just looked and the one other wrong one we have is “noreturn”. It would be great to tackle nonescaping and whatever noreturn should be in the same proposal.

Thanks Erica!

-Chris

Please look through and comment:

didset.md · GitHub

Gist contents pasted below.

Looks good. I’m glad to see a proposal to address this holistically. :)

I do support Brent’s argument that keywords which syntactically appear in the same syntactic location as user-defined names should follow the same convention as those user-defined names. This means, for example, that dynamicType already has the correct case even though it is a keyword. I would like to see this exemption added to the proposal.

Also, with this in mind I would like to see more discussion about the naming convention the community prefers for user-defined behavior accessors (under the assumption that they will make it eventually). If we agree on lowercase for user-defined accessors (which is Chris’s stated preference) I support the change to willset and didset.

However, it is possible that this discussion would result in he community agreeing on lower came case for user-defined behavior accessors. If that is the result then we should not change them.

Most specifically, I would like the discussion to consider whether there may be reallylongbehavioraccessornames that will be completely unreadable in all lowercase (I’m intentionally giving a very extreme example here). Swift favors clarity over conciseness when necessary. Can we really be sure that all accessors for all behaviors will be concise enough for all lowercase names to make sense?

-Matthew

···

On May 20, 2016, at 3:41 PM, Erica Sadun <erica@ericasadun.com> wrote:

On May 20, 2016, at 11:52 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On May 20, 2016, at 10:48 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

On May 20, 2016, at 11:43 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On May 20, 2016, at 10:41 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

-- Erica

Adopting consistent keyword casing in Swift

Proposal: TBD
Author: Erica Sadun <https://github.com/erica&gt;
Status: TBD
Review manager: TBD
<didset.md · GitHub

This proposal adopts consistent conjoined keyword lowercasing.

Swift-evolution thread: RFC: didset and willset <http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534&gt;
<didset.md · GitHub

Swift is an opinionated language. One opinion it adheres to is that keywords should use conjoined lowercasing. Conjoined lowercase terms already in the language include typealias, associatedtype, and fallthrough. Using this casing style enables programmers to treat keywords as atomic concepts. This proposal formalizes this rule and fixes current inconsistencies.

<didset.md · GitHub Casing Rules Roadmap

This proposal addresses the first of the following Swift casing rules:

Keywords use lower case conjoined naming.
Attributes use lower camel cased naming.
Attributes use “non” prefixes in preference to "no" prefixes.
Compiler-expanded literals use lower camel casing and are prefixed with octothorpes (#)
Swift eschews snake casing. (See also: SE-0028 <https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md&gt;\)
Terms of art may be exempted from casing rules.
Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. @UIApplicationMain.
<didset.md · GitHub Language Cleanup Roadmap

This proposal is part of a series that will:

Normalize casing to lower conjoined names.
Normalize naming for "negative" attributes (from "noFeature" to "nonfeaturing").
Move dynamicType to the standard library as a global function.
<didset.md · GitHub Design

Upon adoption, Swift will rename didSet and willSet to willset and didset. Future expansions to the language will follow this adopted rule, for example didchange.

This proposal deliberately omits the dynamicType keyword, which will be addressed under separate cover: to be moved to the standard library as a standalone global function.

<didset.md · GitHub on Existing Code

This proposal requires migration support to rename keywords that use the old convention to adopt the new convention. This is a simple substitution that should limit effect on code.

This proposal recommends deprecating old-style keywords in Swift 2.3 and removing them in Swift 3.

<didset.md · GitHub Considered

Not adopting this rule for Swift.

60

IMHO noreturn is fine. You are indicating "there is no return from this function", as in point of no return.

Also, this is kind of an idiom amongst many programming languages...

···

20. 5. 2016 v 19:55, Erica Sadun via swift-evolution <swift-evolution@swift.org>:

On May 20, 2016, at 11:52 AM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 10:48 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 20, 2016, at 11:43 AM, Chris Lattner <clattner@apple.com> wrote:

On May 20, 2016, at 10:41 AM, Erica Sadun <erica@ericasadun.com> wrote:

Right, but the catfight had a clear outcome:

1) keywords are conjoined
2) attributes are lower camel cased.
3) attributes should use “non” not “no”. noescape should be nonescaping (and thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features? I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left). They will raise different sorts of discussion, even though they both seem obvious to me.

Before putting together a proposal, are there any other de-facto rules besides the three already listed that touch on naming keywords and attributes? (I suppose no snake case is a given)

I think that these are the relevant rules. As I mentioned upthread, .dynamicType is broken for a different reason, and thus leads to a different solution (it should be a global function in the stdlib, not a propery).

-Chris

Separate action items:

* Move dynamicType to standard library as a global function
* Rename didSet and willSet to lowercase to conform to Swift standard of conjoined lowercase keywords.

Sounds great.

* Rename noescape to nonescaping to conform to Swift standard of "non"-modified attributes

I just looked and the one other wrong one we have is “noreturn”. It would be great to tackle nonescaping and whatever noreturn should be in the same proposal.

Thanks Erica!

-Chris

To be clear before I put anything together, `nonreturning`, yes?

-- E

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