Skip to content

Latest commit

 

History

History
77 lines (62 loc) · 2.92 KB

0071-member-keywords.md

File metadata and controls

77 lines (62 loc) · 2.92 KB
Raw

Allow (most) keywords in member references

Introduction

The Swift API Design Guidelines consider enum cases as values that use the lowerCamelCase naming conventions. This means that case names that previously did not conflict with keywords (such as Default, Private, Repeat) now cause conflicts, a problem that is particularly acute when the naming conventions are applied by the Clang importer (per SE-0005). To mitigate this issue, this proposal allows the use of most keywords after a ".", similarly to how SE-0001 allows keywords are argument labels.

This idea was initially discussed in this swift-evolution thread.

Motivation

SE-0005 started lower-camel-casing importer enum cases, which created a number of enum types whose names conflict with keywords. For example:

enum UITableViewCellStyle : Int {
  case \`default\`
  case value1
  case value2
  case subtitle
}

enum SCNParticleImageSequenceAnimationMode : Int {
  case \`repeat\`
  case clamp
  case autoReverse
}

The need to use back-ticks to declare the enumeration is not terribly onerous, especially given that these are Objective-C APIs with very-long names (UITableViewCellStyleDefault, SCNParticleImageSequenceAnimationModeRepeat). However, at the use site, the back-ticks are messy:

let cell = UITableViewCell(style: .`default`, reuseIdentifier: nil)
particleSystem.imageSequenceAnimationMode = SCNParticleImageSequenceAnimationMode.`repeat`

Proposed solution

Allow the use of keywords after the . in a member access, except for those keywords that have special meaning in the language: self, dynamicType, Type, Protocol, (note: this list should track the evolution of the actual language). For example, the above example would become:

let cell = UITableViewCell(style: .default, reuseIdentifier: nil)
particleSystem.imageSequenceAnimationMode = SCNParticleImageSequenceAnimationMode.repeat

Impact on existing code

This change doesn't break any existing code; the back-ticks will continue to work as they always have. As we did with SE-0001, we can provide warnings with Fix-Its that remove spurious back-ticks at use sites. While not semantically interesting, this helps developers clean up their code.