Skip to content

Instantly share code, notes, and snippets.

@erica

erica/didset.md

Last active May 20, 2016 23:17
Show Gist options
  • Save erica/7fa61c3b74b2a2635dbea02120ac5407 to your computer and use it in GitHub Desktop.
Save erica/7fa61c3b74b2a2635dbea02120ac5407 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
didset.md

Adopting consistent keyword casing in Swift

  • Proposal: TBD
  • Author: Erica Sadun
  • Status: TBD
  • Review manager: TBD

Introduction

This proposal adopts consistent conjoined keyword lowercasing.

Swift-evolution thread: RFC: didset and willset

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 use lower case conjoined naming.
  2. Attributes use lower camel cased naming.
  3. Attributes use “non” prefixes in preference to "no" prefixes.
  4. Compiler-expanded literals use lower camel casing and are prefixed with octothorpes (#)
  5. Swift eschews snake casing. (See also: SE-0028)
  6. Terms of art may be exempted from casing rules.
  7. Phrases sourced from outside Swift may be 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 "noFeature" to "nonfeaturing").
  • 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, 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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment