• API의 중요한 가치: 사용 측면에서의 명확성
• 스위프트에서는 모듈별로 로컬 심볼을 만들 수 있기 때문에, 접두사가 필요없다.
  • 하지만 지나치게 일반적인 이름을 쓰면 개발자가 수동으로 모호성을 해소해야 할 수도 있다.
• Value 와 Reference
  • class: 참조 타입
  • struct, enum: 값타입
  • 언제 값타임을 쓰고 참조 타입을 써야 하는가? → 절대적인 룰은 없지만 유즈케이스를 고려해야 한다.
    • 가능하면 클래스보다는 구조체
      • 초기화 위치와 사용 위치가 멀어질 수록, 참조 타입일 경우에는 값 추적이 어렵고 의도치 않은 사이드 이펙트를 유발할 수 있다.
      • 문맥(Semantics)을 고려해서 결정해야 한다.
    • 클래스가 필요한 순간
      • 참조 카운팅과 해제 로직이 필요할 때
      • 값을 중앙에서 가지고 있고, 공유해야 할 때
      • identity와 equalitiy가 다를 때
    • struct안 class 문제
      • 해당 타입이 불변이면 상관없다.
      • 하지면 가변이라면?
        • 불변타입이지만 실제로는 가변 인스턴스인 경우
          • 방어적으로 카피함으로써 막을 수 있다.
        • 타입부터가 가변인 경우
          • Copy-on-Write를 구현한다.
          • isKnownUniquelyReferenced 메소드가 제공된다.
• Protocol과 Generics
  • Objective-C와의 차이: 구조체도 프로토콜을 쓸 수 있다!
  • 프로토콜로 시작하지 말라
    • 구체적인 유즈 케이스로 시작하라
    • 제네릭으로 해결 가능한지 살펴보기
    • 일단 있는 프로토콜로 합성할 수 있을지 살펴보자
    • 프로토콜 대신 제네릭 타입으로 해결 가능한지 살펴보자.
      • 프로토콜의 상속 및 기본 구현 제공으로 해결되지 않는 케이스가 존재할 수 있다.
    • 프로토콜은 코드 재사용이 목적이지, 상속 목적이 아니다.
• KeyPath Member lookup
  • compute property 선언량을 줄일 수 있는 기능
  • 기존에는 string 기반이였는데, 이번에 키패스 기반으로 바뀌어서 타입 안전하고 컴파일 타임에 해줄 수 있는 게 많다.
• Property Wrapper
  • lazy 등의 프로퍼티 초기화/접근 규칙을 언어 수준이 아니라 코드 수준으로 높인 것
  • 컴파일러가 관련 코드를 자동으로 만들어 줌
  • SwiftUI에서 적극적으로 사용