Skip to content

Instantly share code, notes, and snippets.

@erica

erica/didset.md

Last active May 20, 2016 23:17
Download ZIP

Revisions

  1. erica revised this gist May 20, 2016. 1 changed file with 0 additions and 21 deletions.
    21 changes: 0 additions & 21 deletions didset.md
    View file
    Original file line number Diff line number Diff line change
    @@ -19,27 +19,6 @@ use conjoined lowercasing. Conjoined lowercase terms already in the language inc
    `associatedtype`, and `fallthrough`. Using this casing style enables programmers to treat
    keywords as atomic concepts. This proposal formalizes this rule and fixes current inconsistencies.

    #### Swift Casing Rules Roadmap

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

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

    #### Swift Language Cleanup Roadmap

    This proposal is part of a series that will:

    * Normalize casing to lower conjoined names.
    * Normalize naming for "negative" attributes (from "no*Feature*" to "non*featuring*").
    * Move dynamicType to the standard library as a global function.

    ## Detailed Design

    Upon adoption, Swift will rename `didSet` and `willSet` to `didset` and `willset`.
  2. erica revised this gist May 20, 2016. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions didset.md
    View file
    Original file line number Diff line number Diff line change
    @@ -30,6 +30,7 @@ This proposal addresses the first of the following Swift casing rules:
    1. Swift eschews snake casing. (See also: [SE-0028](https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md))
    1. Terms of art may be exempted from casing rules.
    1. Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. `@UIApplicationMain`.
    1. Keywords that appear in the same syntactic locations as user-defined names should follow the convention of those user-defined names.

    #### Swift Language Cleanup Roadmap

  3. erica revised this gist May 20, 2016. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion didset.md
    View file
    Original file line number Diff line number Diff line change
    @@ -41,7 +41,7 @@ This proposal is part of a series that will:

    ## Detailed Design

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

    This proposal deliberately omits the `dynamicType` keyword, which will be addressed
  4. erica revised this gist May 20, 2016. 1 changed file with 0 additions and 2 deletions.
    2 changes: 0 additions & 2 deletions didset.md
    View file
    Original file line number Diff line number Diff line change
    @@ -52,8 +52,6 @@ under separate cover: to be moved to the standard library as a standalone global
    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.

    ## Alternatives Considered

    Not adopting this rule for Swift.
  5. erica revised this gist May 20, 2016. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions didset.md
    View file
    Original file line number Diff line number Diff line change
    @@ -49,10 +49,10 @@ under separate cover: to be moved to the standard library as a standalone global

    ## Impact on Existing Code

    This proposal requires migrator support, renaming keywords using the old convention to
    adopt the new convention. It is a simple substitution that should offer limited effect.
    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.

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

    ## Alternatives Considered

  6. erica revised this gist May 20, 2016. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion didset.md
    View file
    Original file line number Diff line number Diff line change
    @@ -29,7 +29,7 @@ This proposal addresses the first of the following Swift casing rules:
    1. Compiler-expanded literals use lower camel casing and are prefixed with octothorpes (`#`)
    1. Swift eschews snake casing. (See also: [SE-0028](https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md))
    1. Terms of art may be exempted from casing rules.
    1. Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. @UIApplicationMain.
    1. Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. `@UIApplicationMain`.

    #### Swift Language Cleanup Roadmap

  7. erica revised this gist May 20, 2016. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion didset.md
    View file
    Original file line number Diff line number Diff line change
    @@ -42,7 +42,7 @@ This proposal is part of a series that will:
    ## Detailed Design

    Upon adoption, Swift will rename `didSet` and `willSet` to `willset` and `didset`.
    Future expansions to the language will follow this adopted rule, such as `didchange`.
    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.
  8. erica revised this gist May 20, 2016. 1 changed file with 7 additions and 7 deletions.
    14 changes: 7 additions & 7 deletions didset.md
    View file
    Original file line number Diff line number Diff line change
    @@ -7,7 +7,7 @@

    ## Introduction

    This proposal adopts consistent conjoined keyword lowercasing except for well-recognized terms of art.
    This proposal adopts consistent conjoined keyword lowercasing.

    Swift-evolution thread:
    [RFC: didset and willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
    @@ -23,13 +23,13 @@ keywords as atomic concepts. This proposal formalizes this rule and fixes curren

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

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

    #### Swift Language Cleanup Roadmap

  9. erica created this gist May 20, 2016.
    59 changes: 59 additions & 0 deletions didset.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,59 @@
    # Adopting consistent keyword casing in Swift

    * Proposal: TBD
    * Author: [Erica Sadun](https://github.com/erica)
    * Status: TBD
    * Review manager: TBD

    ## Introduction

    This proposal adopts consistent conjoined keyword lowercasing except for well-recognized terms of art.

    Swift-evolution thread:
    [RFC: didset and willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)

    ## Motivation

    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.

    #### Swift Casing Rules Roadmap

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

    1. Keywords are lower case conjoined.
    1. Attributes are lower camel cased.
    1. Attributes use “non” rather than “no”.
    1. Compiler-expanded literals are lower camel cased, prefixed with octothorpes (`#`)
    1. Swift eschews snake case. ([SE-0028](https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md))
    1. Terms of art may be exempted from casing rules.
    1. Phrases sourced from outside Swift are exempted from Swift casing rules, e.g. @UIApplicationMain.

    #### Swift Language Cleanup Roadmap

    This proposal is part of a series that will:

    * Normalize casing to lower conjoined names.
    * Normalize naming for "negative" attributes (from "no*Feature*" to "non*featuring*").
    * Move dynamicType to the standard library as a global function.

    ## Detailed Design

    Upon adoption, Swift will rename `didSet` and `willSet` to `willset` and `didset`.
    Future expansions to the language will follow this adopted rule, such as `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.

    ## Impact on Existing Code

    This proposal requires migrator support, renaming keywords using the old convention to
    adopt the new convention. It is a simple substitution that should offer limited effect.

    I recommend deprecating the old keywords in Swift 2.3 and removing them in Swift 3.

    ## Alternatives Considered

    Not adopting this rule for Swift.