• 사용되는 시점에서 명료함은 가장 중요한 목표이다.
• 명료함이 간단함보다 더 중요하다.

• 당신의 코드베이스에서 예전에 이미 본 것
• 다른 코드베이스에서 예전에 이미 본 것
• 이전 작업에서 그들이 골랐던 사실들

• 그들이 하는 것에 영향을 주는 것
• 그들이 이해할 필요가 있는 것
• 그들이 익숙하지 않은 것
• 정확함, 보안, 성능등의 이유로 특별히 위험한 것

for var i in 0..<10 {
  print(i)
}

struct MyStruct {
  let i: Int
}

struct MyStruct {
  let numberOfInteractions: Int
}

for var i in 0..<10 {

  ...

  ...

  let data = Data(repeating: 0, count: i)

  ...

  ...

  writeToDb(transformedData, i) // Tricky C API...

  ...

  ...

  ...

  let temp = i + 1

  ...
}

print("Hi there!")

class Downloader {
  func cache() { ... }
}

...

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
  func applicationDidFinishLaunching(_ application: UIApplication) {
    ...
    downloader.cache() // Only called at app startup.
  }
}

class Downloader {
  func initializeCache() { ... }
}

extension Downloader {
  func loadDataFieldsFromOfflineCache() { ... }
}

extension Downloader {
  func loadFromCache() { ... }
}

extension Downloader {
  func deleteAPICredentialsFromCache() { ... }
}

extension Downloader {
  func delToken() { /* deletes user data omg! */ }
}

protocol Delegate {
  ...
}

protocol DownloaderDelegate {
  ...
}

class Downloader {
  protocol Delegate {
    ...
  }
}

class Downloader {
  protocol DownloaderDelegate {
    ...
  }
}

class Downloader {
  var downloaderDelegate: Delegate
}

func zipTwoSequences<...>(_ sequence1: Sequence1, _ sequence2: Sequence2) -> ...

func zip<...>(_ sequence1: Sequence1, _ sequence2: Sequence2) -> ...

UIView.animate(withDuration: 1.0, animations: {
  ...
}) { finished in
  ...
}

UIView.animate(withDuration: 1.0, animations: {
  ...
}, completion: { finished in
  ...
})

• 인자들이 유용하게 구별되지 않을때 모든 레이블들을 생략하라.(ex. union(set1, set2))
• 함수 이름의 문법이 첫번째 인자가 무엇인지 명확할때 레이블들을 생략하라.(ex. addSubview(y))
• 타입 규약을 위해서는 레이블들을 생략하라.(ex. Int64(someUInt32))
• 그렇지 않으면 (일반적으로는) 인자 레이블을 명시하라.

(0..<10).map({ String($0) })

(0..<10).map({ number in String(number) })

(0..<10).map({
  ...

  ...

  let data = Data(repeating: 0, count: $0)

  ...

  ...

  return Model(fromData: data, index: $0)
})

기억할것: Swift는 여전히 ABI-안정성이 지원되지 않음!

2.3으로 가야할까 3.0으로 가야할까?

그렇다. 두가지 다이다.

1. 의존성은 중요하다. 여러분의 의존성이 Swift2.3이나 Swift3.0을 지원하는지 확인해야한다. 대부분 주요 라이브러리/프레임워크들은 둘 다 지원하고 있다(Alamofire, Charts). 그러나 기억해야할 것은 Swift3.0을 업그레이드 하는 방법은 하나밖에 없다. Swift3.0으로 새 개발을 시작하고 나면 2.3버전의 모든 의존성이 업데이트 없이는 작동하지 않을 것이다.
2. 8.x 버전의 Xcode는 Swift2.3 지원을 멈출 것이다. Swift2.3은 Swift3.0으로 업그레이드 하기 힘든 프로젝트를 위한 매개 단계의 경향이 있다.
3. 만약 여러 프로젝트에 걸쳐진 개인의 CocoaPods이 있다면 먼저 이것부터 업그레이드 해야한다.

Swift2.2에서 2.3으로 마이그레이션 이슈

Swift2.x에서 Swift3.0으로의 마이그레이션 이슈

Swift2.3

Swift3.0

(인지할만한)주요 변화들

1. 외부모듈이 클래스나 맴버를 사용할 수 있다.
2. 외부모듈이 클래스나 맴버를 오버라이드 할 수 있다.

// Before
let red = UIColor.redColor().CGColor
// After
let red = UIColor.red.cgColor

이제부터 id는 'AnyObject'가 아닌 'Any'로 불러오기 때문에, 이전에 여러분이 'AnyObject'로 동적인 검색을 수행하는 곳에서 애러가 뜰 수도 있다.

(인식하지 못할지도 모르는)작은 변화들

1. toNearestOrAwayFromZero
2. toNearestOrEven
3. towardZero
4. awayFromZero

굳이 걱정하지 않을 정도로 작은 것

이 모든 변화가 Swift3에서 일나날까?

1. Sequence-기반 생성자를 추가하고 Dictionary에 메소드를 합친다.
2. 약 참조(weak reference)에서 강 참조(strong reference)로 self를 업그레이드하여 옵셔널 바인딩을 사용할 수 있게 해준다.
3. 표준 라이브러리에 AnyHashable을 추가한다.

1. 순환 알고리즘
2. .self 제거
3. 커스텀 Objective-C 표현을 제공하는 것을 Swift 타입에서 허용
4. 동적 케스터로부터 연결 변환 동작을 제거
5. Sequence end-operation 이름을 합리화

보너스

1. Swift 언어에서 where문 제거
2. 인스턴스 맴버를 접근하기 위해 self가 필요함
3. extension에서 접근 변경자 제거