[WWDC2022]Eliminate data races using Swift Concurrency

Task에 대하여

일단 설명을 위해서 concurrency한 환경을 '바다'로 비유하고, Task를 '배'로 표현한다.

Task는 특정 작업을 시작부터 끝까지 수행하며 다음과 같은 특징을 지닌다.

• 순차적 (Sequential)
• 비동기적 (Asynchronous)
• 독립적 (Self-contained)

이 Task라는 배는 독립적이며 자체 리소스를 가지고 있으므로 다른 배들과 독립적으로 작동한다. 따라서 서로의 독립적인 배들은 서로 아무런 영향을 주지 않기 때문에 이론적으로는 Data Race에서 안전하다.

하지만, 실제 작업 환경에서는 이 배들간의 커뮤니케이션이 이루어진다. 여기서는 이 커뮤니케이션을 배들끼리 물건을 주고 받는 것으로 비유한다.

예시

물건에는 아래와 같이 두가지 종류가 있음.

• 파인애플(Structure)
• 닭(Class)

각각의 코드는 다음과 같다.

// 파인애플 코드

enum Ripeness {
    case hard
    case perfect
    case mushy(daysPast: Int)
}

struct Pineapple {
    var weight: Double
    var ripeness: Ripeness

    mutating func ripen() async {...}
    mutating func slice() -> Int { ... }
}

// 닭 코드

final class Chicken {
    let name: String
    var currentHunger: HungerLevel

    func feed() { ... }
    func play() { ... }
    func produce() -> Egg { ... }
}

자, 우선 한배에서 다른배로 파인애플을 전달한다고 가정한다. 여기서 파인애플은 Structure이며 Value Type이다. 복사본이라는 뜻이며 값만 같을 뿐 동일한 인스턴스를 참조하는 것은 아니다.

따라서 각각의 배에서 파인애플을 slice() 및 ripen() 하더라도 각각의 배에는 영향을 주지 않는다.

즉, value type은 data race에 상대적으로 안전하며 Swift가 Value Type을 선호해왔던 이유이다.

그렇다면 닭을 전달하는 경우에는 어떠할까? 닭은 Class이며 Reference Type이다. 두 배가 같은 인스턴스를 참조한다. 즉, 독립적이지 않다.

따라서 각각의 배에서 feed() 및 play()를 수행할 경우 Data Race가 발생할 수 있다. 이를 해결하기 위해서는 무엇을 해야할까?

Sendable

Sendable에 대하여

우선 다음과 같은 판단 기준이 필요하다.

• 파인애플은 배 사이 에서 공유하는 것이 안전하지만, 닭은 공유할 수 없음을 알 수 있는 방법
• 닭이 실수 로 한 보트에서 다른 보트 로 전달되지 않도록 Swift 컴파일러에서 검사

위의 역할을 수행하는 것이 바로 Sendable Protocol이다.

Sendable (protocol) 복사를 통해서 동시성(concurrency) 도메인 간에 안전하게 값을 전달할 수 있는 타입. A type whose values can safely be passed across concurrency domains by copying.

파인애플(structure)은 Value Type이기 때문에 Sendable을 따르지만, 닭(class)는 동기화 되지않은(unsynchronized) Reference Type이기 때문에 Sendable을 따를 수 없다.

Task간의 Sendable 검사

Sendable protocol을 사용하면 데이터가 격리 도메인(Isolation Domain)에서 공유되는 위치를 설명할 수 있다. 예를 들어 아래와 같은 코드가 있다.

let petAdoption = Task {
    let chickens = await hatchNewFlock()
    return chickens.randomElement()!
}
let pet = await petAdoption.value

Task에서 Chicken을 반환하려고 하지만, 치킨은 Sendable하지 않기 때문에 안전하지 않다는 오류가 발생한다.

Error: type Chicken does not conform to the Sendable protocol

Task가 어떻게 정의되어있는지 살며보면 아래와 같이 Task의 결과 값인 Success가 Sendable을 채택고 있다.

@frozen struct Task<Success, Failure> where Success : Sendable, Failure : Error

따라서 서로 다른 격리 도메인(Isolated Domain)간에 전달될 Generic Parameter 또한 Sendable을 따라야한다.

Sendable 전파

Sendable은 조건부 적합성(conditional conformance)을 통해 Collection 및 Generic Type에 전파될 수 있다. 아래의 코드를 보자

✅ enum Ripeness: Sendable {
    case hard
    case perfect
    case mushy(daysPast: Int)
}

✅ struct Pineapple: Sendable {
    var weight: Double
    var ripeness: Ripeness
}

✅ struct Crate: Sendable { 
    var pineapples: [Pineapple]
}

❌ struct Coop: Sendable { 
    var flock: [Chicken]
}

우선 enum과 struct 모두 Value Type이기 때문에 Ripeness와 Pinapple모두 Sendable을 채택할 수 있다. 그리고 Crate에서 Collection pinapples은 Senable을 채택하는 Pineapple을 담고 있기 때문에 Sendable이다.

하지만 Coop에 Sendable을 적용시키려하면 에러가 난다.

Error: stored property flock of Sendable - conforming struct Coop has non-sendable type [Chicken]

Chicken은 Sendable타입을 적용하지 않고 있다. 따라서 Chicken을 담고 있는 Collection flock는 Sendable이 아니며, 이로 인해서 Coop또한 Sendable을 채택할 수 없다.

Reference Type에 Sendable 적용하기

Class에 Sendable을 적용시키는 것이 불가능한 것은 아니다. 다만, 아래 조건을 만족하는 매우 좁은 상황에서만 Sendable로 만들 수 있다.

• final class이어야함.
• 변경 불가능한 저장소(immutable storage)만 포함해야함.

final class Chicken: Sendable {
    let name: String
    var currentHunger: HungerLevel ❌
}

위의 코드는 아래와 같은 에러를 만든다.

Error: class Chicken cannot conform to Sendable Error: stored property currentHunger of Sendable - conforming class Chicken is mutable

currentHunger는 변경 가능하다(mutable). 따라서 Chicken은 Sendable을 채택할 수 없다.

만약 Chicken을 Sendable하게 만들고 싶다면, 현재 상태에서 immutable한 name만을 포함해야한다.

사실 lock를 일관적으로 사용하는 방법과 같이 내부적인 동기화 작업을 수행하는 Reference Type을 포함하는 방법이 있기는 하다.

class ConcurrentCache<Key: Hashable & Sendable, Value: Sendable>: @unchecked Sendable {
    var lock: NSLock
    var storage: [Key: Value]
}

이러한 유형은 개념적으로는 Sendable 이지만 Swift가 이에 대해 알 수 있는 방법이 없다. 따라서 컴파일러의 검사를 비활성화 하기 위해서 @unchecked Sendable을 사용한다. 다만, 이 경우에는 Swift가 Data Race Safety를 보장할 수 없기 때문에 매우 주의해야한다.

Task 생성시 Sendable 검사

Task를 생성하는 방법 중에는 기존의 Task내에서 완전히 새롭고 독립된 새로운 Task를 closure를 통해 생성하는 방법이 있다.

위에서 Task를 배로 비유한것으로 설명하자면 기존의 배에서 조그마한 카약을 띄우는 식이다.

이 경우에는 기존 Task(배)에서 값을 캡처 하여, 새 Task(카약)로 전달할 수 있는데 Data Race가 발생할 수 있으므로 Sendable 검사를 수행한다.

let lily = Chicken(name: "Lily")
Task.detached {
    lily.feed()
}

위의 코드는 sendable이 아닌 lily를 전달하므로 아래과 같은 에러를 발생시킨다.

Error: capture of lily with non-sendable type Chicken

detached 함수는 아래와 같이 작성되어있다.

struct Task<Success: Sendable, Failure: Error> {
    static func detached(
        priority: TaskPriority? = nil,
        operation: @Sendable @escaping () async throws -> Success
    ) -> Task<Success, Failure>
}

operation: @Sendable를 보면 알 수 있듯이 해당 함수 유형이 sendable을 준수하고 있다는 것을 보여준다.

즉, 위에서 오류가 났던 코드는 아래와 같이 작성된 것과 같으며 이를 통해 Sendable closure로 유추되는 것이다.

let lily = Chicken(name: "Lily")
Task.detached { @Sendable in
    lily.feed()
}

결론

Sendable을 체크함으로써 Task Isolation을 유지할 수 있다.

• Task는 격리되어있고, 독립적으로 비동기(asynchronous) 작업들을 수행한다.
• Sendable은 각 Task들이 격리되어있다는 것을 보장한다.
• 따라서 값들이 교환되어야 하는 모든 곳에서 Sendable이 사용되어야한다.

다음 포스트 - Actor Isolation

Task를 격리하는 것은 Data Race를 방지하는 좋은 방법이지만, 다음과 같은 큰 문제가 있다.

공유된 변경 가능한 데이터(shared mutable data)가 없다면, Task들을 의미있게 사용하기 어렵다.

따라서 Data Race를 일으키지 않는 작업 간에 데이터를 공유할 수 있는 방법이 필요하다. 여기에 Actor Isolation이 등장한다. (Actor Isolation 작성예정)

Async/Await등의 Concerrency 기능들을 이제는 더 낮은 버전부터 사용가능.

• macOS 10.15(catalina)
• iOS13
• tvOS13
• watchOS6

Data race avoidance

Swift는 data race가 발생하여 memory safety하지 않은 지점들을 알려줘왔었고, 작년에는 Actor등을 도입하여 data race를 방지 할 수 있는 방법들을 제공해 왔다. Swift의 최종목표는 memory safety를 넘어서 thread safety로, 올해에는 작년보다 더 다양한 concerrency 방법들을 제공할 예정이라고 한다.

자세한 내용은 Eliminate data races using Swift Concerrency 세션 참조.

Distributed actors

분산 시스템을 위한 Distributed Actor가 추가됨. 고립성과 위치 투명성을 통해서 네트워킹등의 우발적 복잡성등을 피하는데 도움을 주는 역할을 한다고 함.

자세한 내용은 Meet distributed actors in Swift 세션 참조.

Async algorithms

swift5.5에서 제공하는 AsyncSequence를 더 쉽게 처리하기 위한 솔루션으로 새로운 오픈소스 알고리즘 세트를 공개함. zip(), merge(),debounce(),chunked()등을 제공하며 자세한 내용은 Meet Swift Async Algorithms세션 참조

Actor prioritization(concurrency optimization)

이제부터 Actor는 Actor prioritization을 통해서 우선순위가 높은 작업부터 수행함.

Swift Concurrency Instrument

일반적으로 concurrency가 앱의 성능에 미치는 영향등을 시각화하기 어려움. 이를 해결할 concurrency 시각화 도구인 Swift Concurrency Instrument가 추가됨.

자세한 내용은 Visualize and optimize Swift concurrency세션 참조.

참고자료

• https://developer.apple.com/videos/play/wwdc2022/110354/

차이점

Protocol과 Opaque Type의 가장 큰 차이점은 Type Identity의 여부이다.

• Protocol: Type Identity를 가지지 않는다.
• Opaque Type: Type Identity를 가진다.

이로 인해서 실제 사용시 다음과 같은 차이가 발생한다.

1. Return Value

다음과 같은 코드가 있다.

protocol Quadrilateral {
    var width: Float { get set }
    var height: Float { get set }
}

struct Square: Quadrilateral {
    var width: Float
    var height: Float
}

struct Rectangle: Quadrilateral {
    var width: Float
    var height: Float
}

struct InversedRectangle: Quadrilateral {
    var width: Float
    var height: Float

    init(rectangle: Quadrilateral) {
        self.width = rectangle.height
        self.height = rectangle.width
    }
}

func getProtoQuadrilateral<T: Quadrilateral>(_ shape: T) -> Quadrilateral {
    if shape is Square { return shape }
    return InversedRectangle(rectangle: shape)
}

// Error: Function declares an opaque return type, but the return statements in its body do not have matching underlying types
func getOpaqueQuadrilateral<T: Quadrilateral>(_ shape: T) -> some Quadrilateral {
    if shape is Square { return shape }
    return InversedRectangle(rectangle: shape)
}

잠시 코드를 설명하자면, 높이(height)와 너비(width) 변수를 가지는, 사각형을 뜻하는 Quadrilateral Protocol이 존재한다.

그리고 이 Protocol을 준수하는 다음과 같은 세가지 structure가 존재한다.

• Square: 정사각형
• Rectangle: 직사각형
• InversedRectangle: 입력받은 Quadrilateral의 높이와 너비를 뒤바꾼 Quadrilateral

아래에는 두개의 function getProtoQuadrilateral와 getOpaqueQuadrilateral이 있는데, 두 function 모두 Quadrilateral를 parameter로 받아서 Sqaure일 경우 그대로 return하고, Square이 아닐 경우 해당 Quadrilateral을 뒤집은 InversedRectangle을 return 한다.

이떄 OpaqueType을 return하는 getOpaqueQuadrilateral에서 error가 발생하는 것을 확인 할 수 있는데, 이는 getOpaqueQuadrilateral이 상황에 따라서 Squre 또는 InversedRectangle을 return 할 수 있기 때문이다.

OpaqueType은 Type Identity를 가지고 있고, 이 때문에 함수 return시에 하나의 구체 Type만을 return해야한다. 즉, Quadrilateral을 만족하는 한 가지 Type의 return만 가능한 것이다.

반면, Protocol은 Quadrilateral을 채택하는 모든 Type을 return 할 수 있다.

요약 OpaqueType은 하나의 구체 Type만을 return. Protocol은 모든 Type을 return.

2. Self 및 associatedType 사용

위에서 Protocol은 Type Identity를 가지지 않고, Opaque Type은 Type Identity를 가진다고 했다. Type Identity의 여부는 Self 및 associatedType의 추론 조건중 하나이다. 즉, Type Identity를 가지지 않게 되면 Self 및 associatedType을 추론할 수 없으므로 이를 return 값으로 사용할 수 없다.

아래에서 조금 더 자세히 살펴보자.

Equatable의 == Operator는 (Self, Self)를 parameter로 받는다. Self는 보통 Protocol을 채택하는 어떠한 구체적인 Type과 매칭되지만, 앞서 말했듯이 Protocol은 Type에대한 Identity를 가지고 있지 않으므로 Self를 사용할 수 없다. 즉, protocol은 == Operator을 사용할 수 없다.

다음은 associatedType이 적용된 경우 Protocol을 return 할 수 없는 이유이다. 다음과 같은 코드가 있다.

protocol Container {
    associatedtype dataType
    var dataArray: [dataType] { get set }
}

struct IntContainer: Container {
    var dataArray: [Int] = [1, 2, 3, 4, 5]
}

struct StringContainer: Container {
    var dataArray: [String] = ["One", "Two", "Three", "Four", "Five"]
}

// Error: Protocol 'Container' can only be used as a generic constraint because it has Self or associated type requirements
let containerProto: Container = IntContainer()
// OK
let containerOpaque: some Container = IntContainer()

let containerProto는 Container protocol을 값으로 받으려고 하는데, protocol은 Type Identity가 없으므로 외부에서 associatedType을 추론하기 위한 충분한 정보가 없다. 따라서 protocol을 반환 할 수 없으므로 error가 발생한다.

반면 Opaque Type을 받는 containerOpaque는 Type Identity를 가지고 있으므로 AssociatedType을 추론할 수 있다. 즉, return값으로 사용할 수 있게 된다.

요약 associatedType 및 Self를 사용하고자 하는 경우, Opaque Type을 return하여 사용하여야 한다.

참고자료

https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes.html

Generic 코드

func max<T>(_ x: T, _ y: T) -> T where T: Comparable { ... }

Gerneric을 사용한 코드에서 Type이 선택되는 때는 언제일까?

다음 함수를 Call한다고 할 때 Caller는 x, y의 Type을 선택하게 된다. 즉, Caller가 Type을 선택하게 된다.

함수가 Call될때 Type이 선택되기 때문에, 함수는 Call되기 전까지 GenericType T가 Comparable을 준수하는 Type이란 것을 제외하고는 아무것도 모른다. 즉, parameter의 Type에 대응하기 위해서, 해당 함수의 구현부는 추상적으로 작성되어야 한다.

Opaque Type

Opaque Type 코드

struct Square: Shape {
    var size: Int
    func draw() -> String {
        let line = String(repeating: "*", count: size)
        let result = Array<String>(repeating: line, count: size)
        return result.joined(separator: "\n")
    }
}

func makeTrapezoid() -> some Shape {
    let top = Triangle(size: 2)
    let middle = Square(size: 2)
    let bottom = FlippedShape(shape: top)
    let trapezoid = JoinedShape(
        top: top,
        bottom: JoinedShape(top: middle, bottom: bottom)
    )
    return trapezoid
}
let trapezoid = makeTrapezoid()
print(trapezoid.draw())

Opaque를 사용한 코드에서 Type이 선택되는 때는 언제일까?

함수의 구현부를 살펴보면 구체적인 Type을 생성한 후에 return하게 된다. 즉, 함수 구현부가 Type을 선택하게 된다.

함수 구현부에서 Type이 선택되기 때문에, 함수의 Caller는 return되는 값이 Shape protocol을 준수한다는 것을 제외하고는 아무것도 모른다. 즉, 함수의 return type에 대응하기 위해서, 해당 함수의 Caller는 추상적으로 작성되어야 한다.

정리

위의 내용들을 정리하면 다음과 같다.

Type이 선택되는 곳.

• Generic: 함수 호출자가 Type을 선택.
• Opaque: 함수 구현부가 Type을 선택.

추상적으로 작성되어야 하는 곳

• Generic: 함수 구현부.
• Opaque: 함수 호출자.

혹시 눈치를 챘을 수도 있지만, Opaque Type은 Generic과 반대의 성격을 가지고 있는 것을 볼 수 있다. 때문에 Opaque Type을 Reverse Generic이라고도 부른다.

참고자료

https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes.html

SwiftUI를 이용한 프로젝트를 진행하고 있는데 이상한 점을 발견했다.

아래의 예시 코드를 보자.

struct ChildView: View {
    enum FocusedField {
        case firstField
        case secondField
    }
    @State private var firstText = ""
    @State private var secondText = ""
    @FocusState private var focusedField: FocusedField?

    var body: some View {
        TextField("test", text: $firstText)
            .focused($focusedField, equals: .firstField)

        TextField("test", text: $secondText)
            .focused($focusedField, equals: .secondField)
    }
}

지금 보이는 ChildView는 두개의 TextField를 가지고 있다. 각각의 TextField는 focusedField를 바인딩하여 focused를 관리하도록 되어있다. 이는 Apple의 공식문서의 내용과 동일하다.

ChildView는 ParentView에서 event를 받아 화면에 나타난다. 그 방식이 NavigationLink이던, Sheet이던 아무 상관없다.

문제는 ChildView를 닫아 ParentView로 돌아와도 @FocusState의 잔재로 추정되는 메모리가 남아있다는 것이다. 몇번이고 ChildView를 열었다가 닫으면 계속해서 누수가 발생한다. 아래 사진은 처음 ChildView를 열고 닫았을 때 발생했던 MemoryLeak이다.

실제 focusedField 때문인지 확인해보기 위해서 해당 코드들을 지우고 다시 실행해보았다. 결과는 더이상 MemoryLeak가 발생하지 않는다. focused(_:equals:)를 없애면 해당 문제가 발생하지 않는데, 여기서 발생하는 문제 같다.

해결방법

못찾았다... 아직 내가 이해도나 실력이 부족해서인지, 실제 SwiftUI내에서 발생하는 문제인지 모르겠다... 이와 관련된 내용을 아무리 검색해보아도 나오지 않으니 답답할뿐이다. 그냥 FocusState를 이용하지 말고 ViewModel에 직접 Focus를 구분하는 방식의 로직을 만들어서 View랑 바인딩해야겠다...

[weak self]를 활용하여 closure에서의 순환참조를 꼭 해결하자...

발생한 오류

RxSwift를 활용한 채팅 앱을 만들고 있었다. 친구목록을 보여주는 FriendListView에서 친구를 선택하면 UINavigationController를 통해서 친구와의 채팅화면을 보여주는 ChatRoomView로 이동을 하게 된다.(FriendListView와 ChatRoomView는 각각의 ViewModel로 Bind되어있다.) 이후 ChatRoomView를 Pop하여 FriendListView로 되돌아 왔는데, Xcode의 Debug Navigator의 메모리 사용량이 그대로이다... 뭔가 이상함을 느껴서 위의 동작을 여러번 수행해봤는데, 아니나 다를까 ChatRoomView의 메모리 해제가 수행되지 않고 있었다...

해결 과정

처음에는 RxSwift의 DisposeBag에서 Dispose가 일어나지 않는 것이 원인이라 생각했다. DisposeBag의 Dispose를 수행하는 위치에 Log들을 찍어보았지만, 우리의 DisposeBag는 정상적으로 동작하고 있었다.

원인을 찾아야 해결할 수 있다는 생각에 memory leak를 해결하는 방법을 찾다가 Xcode에서 지원하는 여러가지 기능들을 알게 되었다. Debug Memory Graph와 Instruments Profiling의 Leaks가 그것인데, 이와 관련해서는 좀 더 사용을 해보고 나중에 글을 작성해보는 것도 좋겠다.

아무튼, Memory Leak를 통해 점점 쌓여가는 ChatRoomView와 ChatRoomViewModel을 확인해보니 모두 RxSwift Closure의 Strong Reference로 인한 문제였다. 이 부분에서 아차 싶었다. 당연히도 Closure에서의 Circular Reference를 고려했어야 했는데, 전혀 생각지 못한 상태로 앱을 만들고 있었다... 역시 아직 갈길이 멀구나...

해결 방법

RxSwift의 Closure들이 Self를 Strong하게 물고 있다는 원인이 파악되었으니, 해결하는 방법은 간단했다. [weak self]를 사용하여 weak reference를 적용시켜주면 된다. 너무나 쉽다... 세상에...

추가 자료

https://velog.io/@haanwave/Article-You-dont-always-need-weak-self

VC1에서 prefersLargeTitles를 true로 놔둔 상태에서 VC2의 largeTitleDisplayMode를 .always 또는 .never로 설정하는 것이 답이였다.

발생한 오류

NavigationController가 Embed된 VC1, 그리고 VC2가 있다고 가정하자. 내가 구현하고 싶었던 것은 VC1에서 VC2로 이동할 때 VC1의 title은 크게, VC2의 title은 작게 설정하는 것이였다.

하지만 여러 시도에도 불구하고 다음과 같은 오류들이 발생했다.

• VC1과 VC2의 title이 모두 크게 설정됨.
• VC1에서 VC2로 이동시 title이 작아지기는 하나, VC1으로 다시 이동하면 VC1은 작은 상태임.

문제의 코드

나는 title을 VC1의 prefersLargeTitles의 값으로만 제어하려 했다. 따라서 문제의 코드는 다음과 같은 모습을 보였다. VC1

override func viewWillAppear(_ animated: Bool) {
    self.navigationController?.navigationBar.prefersLargeTitles = true
        self.navigationController?.navigationBar.sizeToFit()
}

//VC2로의 transition 완료(본코드에는 RxSwift 활용)
transitionToVC2Complete() {
    self.navigationController?.navigationBar.prefersLargeTitles = false
}

해결방법

이 문제를 해결하는 법은 title의 크기를 prefersLargeTitles로 control하는 것이 아닌, navigationItem의 largeTitleDisplayMode를 사용하는 것이였다.

VC1에서 prefersLargeTitles를 true로 놔둔 상태에서 VC2의 largeTitleDisplayMode를 .always 또는 .never로 설정하는 것이 답이였다.

즉 다음과 같이 작성해야 정상적으로 작동한다. 세상에... VC1

override func viewDidLoad() {
        super.viewDidLoad()
        self.navigationController?.navigationBar.prefersLargeTitles = true
}

override func viewWillAppear(_ animated: Bool) {
        self.navigationController?.navigationBar.sizeToFit()
}

VC2

override func viewDidLoad() {
        super.viewDidLoad()
        self.navigationItem.largeTitleDisplayMode = .never
    }

참고자료

• https://sujinnaljin.medium.com/rxswift-subject-99b401e5d2e5
• https://ntomios.tistory.com/12

Protocol에서 타입의 견본을 주는(placeholder) Generic 개념.

기본 개념

PlaceHolder 역할

An associated type gives a placeholder name to a type that’s used as part of the protocol. associated type은 protocol에 사용되는 타입의 견본(placeholder name)을 주는 역할을 한다.

Generic에 포함된 개념이다. 한 마디로 protocol을 작성할 때 각각의 property에 적용하는 Generic Type이라고 생각할 수 있다.

예시

다음과 같은 NumberProtocol이라는 protocol이 있다고 가정하자. 그 안의 thousand property는 1,000의 자리 숫자를 가진다. 그 값은 Int형 일 수도 있고 String형 일 수도 있다. 이를 해결하기 위해서 associated type Number을 설정한다.

protocol NumberProtocol {
    associatedtype Number
    var thousand: Number { get }
}

Int형 thousand을 가지는 NumberInt struct는 다음과 같이 만들 수 있다.

struct NumberInt: NumberProtocol {
    var thousand: Int {
        return 1000
    }
}

String형 thousand을 가지는 NumberString struct는 다음과 같이 만들 수 있다.

struct NumberString: NumberProtocol {
    var thousand: String {
        return "1000"
    }
}

제약 설정

associated type에는 제약도 설정해 줄 수 있다.

예시

다음과 같이 associated type Number에 Equatable 제약을 설정한다.

protocol NumberProtocol {
    associatedtype Number: Equatable
    var thousand: Number { get }
}

위에서 작성한 Int형과 String형을 가지는 Struct들은 오류가 발생하지 않는다. 기본적으로 Swift의 Int형과 String형 모두 Equatable을 준수하기 때문이다.

struct NumberInt: NumberProtocol {
    var thousand: Int {
        return 1000
    }
}

struct NumberString: NumberProtocol {
    var thousand: String {
        return "1000"
    }
}

하지만 커스텀으로 작성한 NotEquatableclass를 제약을 걸어둔 associated type Number에 넣을 경우 Error을 띄우게 된다. NotEquatable은 Equatable을 준수하고 있지 않기 때문이다.

참고자료

• https://docs.swift.org/swift-book/LanguageGuide/Generics.html#//apple_ref/doc/uid/TP40014097-CH26-XID_283
• https://zeddios.tistory.com/382

weak(optional) vs unowned(non-optional)

개념

weak와 unowned는 Strong Reference Cycle을 해결하기 위해서 사용한다. 두 방식의 차이는 optional과 non-optional의 차이이다.

weak의 경우에는 optional을 사용해야한다. unonwed는 값이 무조건 있다고 가정하고 사용하기 때문에 optional을 채택해서는 안된다.

다음은 weak를 사용한 코드이다.

class Company {
    let name: String
    weak var car: Car?

    init(name: String) {
        self.name = name
        print("Company Init")
    }

    deinit { print("Company Deinit") }
}

class Car {
    let name: String
    var company: Company?

    init(name: String) {
        self.name = name
        print("Car Init")
    }
    deinit { print("Car Deinit") }
}


var k8: Car? = .init(name: "k8")    // Car Init
var kia: Company? = .init(name: "KIA")    // Company Init

k8?.company = kia
kia?.car = k8

k8 = nil    // Car Deinit
kia?.car    // nil

Company(kia)와 Car(k8) 두개의 class가 서로를 property로 가리키고 있는 상태에서, Car을 해제한 후 Company의 property car을 출력해보니 nil이 출력되는 것을 볼 수 있다.

weak는 기본적으로 가리키던 instance가 메모리에서 해제될 경우 nil이 할당된다. 따라서 Company(kia)의 property car이 가리키던 Car(k8)이 해제되자 car에는 nil이 할당 된 것이다.

그렇다면 위의 코드에 weak를 unowned로 바꾸면 어떻게 될까?

class Company {
    let name: String
    unowned var car: Car?

    init(name: String) {
        self.name = name
        print("Company Init")
    }

    deinit { print("Company Deinit") }
}

class Car {
    let name: String
    var company: Company?

    init(name: String) {
        self.name = name
        print("Car Init")
    }
    deinit { print("Car Deinit") }
}


var k8: Car? = .init(name: "k8")    // Car Init
var kia: Company? = .init(name: "KIA")    // Company Init

k8?.company = kia
kia?.car = k8

k8 = nil    // Car Deinit
kia?.car    //Error

위와 같이 Error을 띄우게 된다. weak와 달리 unowned는 가리키던 instance가 해제되면 nil을 반환하지 않는다. 대신 해제된 메모리 주소값을 계속해서 들고 있는다. 따라서 이에 접근하려 할 경우, 다음과 같이 Error을 뿜어낸는 것이다.

이러한 이유로 unowned는 non-optional로 설정해야한다. 다음과 같은 코드가 unowned를 바르게 사용하는 코드이다.

class Company {
    let name: String
    unowned let car: Car

    init(name: String, car: Car) {
        self.name = name
        self.car = car
        print("Company Init")
    }

    deinit { print("Company Deinit") }
}

class Car {
    let name: String
    var company: Company?

    init(name: String) {
        self.name = name
        print("Car Init")
    }
    deinit { print("Car Deinit") }
}

참고자료

https://babbab2.tistory.com/27 http://minsone.github.io/mac/ios/rules-of-weak-and-unowned-in-swift https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html

어떠한 함수를 사용했지만 반환값을 활용하지 않았을 경우, swift는 경고문을 띄워준다. 이 경고를 제거하기 위해서 @discardableResult를 사용한다.

개념

discardable result 버릴 수 있는 결과

다음과 같은 plus 함수가 있다고 가정한다.

func plus(_ n1: Int, _ n2: Int) -> Int {
        return n1 + n2
}

plus 함수를 사용하였지만, 반환값 Int 를 활용하지 않았다.

plus(1, 2)

이 경우 Swift는 다음과 같이 경고를 보여준다.

해당 경고를 없애기 위해서 @discardableResult를 사용한다.

활용

plus 함수 위에 @discardableResult를 추가한다.

@discardableResult
func plus(_ n1: Int, _ n2: Int) -> Int {
        return n1 + n2
}

경고가 사라진 모습을 볼 수 있다.

Equatable Protocol을 적용하여 Custom Type끼리의 비교가 가능하다

기본 개념

A type that can be compared for value equality. 값이 동일한지 비교할 수 있는 Type

Swift 공식 문서에 정의되어있는 Equatable의 개념이다.

Swift 기본 Type들은 대부분 Equatable을 따른다. Equatable을 따르는 Type들은 같다(==)와 같지 않다(!=) 연산자를 사용할 수 있다. 아래 코드와 같이 말이다.

var c1 = "ABC"
var c2 = "ABC"
var c3 = "XZY"

print(c1 == c2 ? true : false)
// true

print(c1 != c2 ? true : false)
// false

print(c2 == c3 ? true: false)
// false

활용

기본적으로 Swift에서 Class, Structure, Enum과 같은 CustomType은 서로 비교 불가하다.

class StreetAddress {
    let number: String
    let street: String

    init(_ number: String, _ street: String) {
        self.number = number
        self.street = street
    }
}

print(StreetAddress("1", "A") == StreetAddress("1", "A") ? true : false)
//Error: binary operator '==' cannot be applied to two 'StreetAddress' operands

다음과 같이 StreetAddress에 대하여 == 연산자 적용이 불가능하다는 Error가 뜬다.

하지만 이러한 상황에서 Class, Structure, Enum등을 비교하고 싶을 경우, Equatable을 사용하면 된다.

Equatable은 Protocol이다. 위에서 말했듯이 Equatable을 따르는 Type들은 서로 같은지 비교할 수 있다. 한마디로 Equatable을 적용할 경우 Class, Structure, Enum 등을 비교할 수 있다.

class StreetAddress: Equatable {
    static func == (lhs: StreetAddress, rhs: StreetAddress) -> Bool {
        return
            lhs.number == rhs.number &&
            lhs.street == rhs.street
    }

    let number: String
    let street: String

    init(_ number: String, _ street: String) {
        self.number = number
        self.street = street
    }
}

print(StreetAddress("1", "A") == StreetAddress("1", "A") ? true : false)
// true
print(StreetAddress("1", "A") != StreetAddress("1", "A") ? true : false)
// false
print(StreetAddress("1", "A") == StreetAddress("2", "B") ? true : false)
// false

Euatable을 적용하고 해당 프로토콜에서 요구하는 static func == (lhs: Self, rhs: Self) -> Bool 을 작성했더니 StreetAddress Class끼리 비교가 가능해졌다. static func == (lhs: Self, rhs: Self) -> Bool 내부에는 비교할 Type의 모든 Property들이 같은지 확인하여 반환하면 된다.

• Class와 Struct는 swift의 근간을 이루는(객체지향) 매우 중요한 핵심 요소이다.
• Class와 Struct는 Member(Property / Method)를 포함한다.
  • Property : Struct와 Class 내부에서 정의된 변수나 상수.
  • Method : Struct와 Class 내부에 정의된 함수.

Class VS Structure

공통점

* Property 및 메소드 정의
* 서브스크립트 정의
* 초기화 블록 정의
* 확장(extends) 구문
* 프로토콜 구현

차이점(Class만 가능한 것들)

* 상속
* 타입 캐스팅
* 소멸화 구문
* 참조에 의한 전달(Struct는 값에 의한 전달) 

Struct 사용 목적

• 서로 연관된 몇 개의 기본 데이터 타입 캡술화.
• 상속이 필요하지 않을때.
• 데이터 전달 방식이 값에 의한 전달일 경우 더 효율적일 때.
• 캡슐화된 원본 데이터 보존.

값 전달 방식

• Class : 참조에 의한 전달(Reference Type)
• Struct : 값에 의한 전달(Value Type)

Class - 참조에 의한 전달(Reference Type)

• 한 곳에서 수정할 경우 다른 곳에도 적용된다.
• 하나의 Class Instance는 오로지 하나의 변수/상수만이 참조할 수 있다.
• 하나의 Class Instance를 여러 변수나 상수, 또는 함수의 인자값에서 동시에 참조할 수 있다.

class VideoMode {
var interlaced = false
var frameRate = 0.0
var name: String?
}

func changeName(v: VideoMode) {
    v.name = "Function Video Instance"
}

let video = VideoMode()
video.name = "Original Video Instance"
print("video 인스턴스의 name 값은 \(video.name!)입니다.")
//video 인스턴스의 name 값은 Original Video Instance입니다.

let dvd = video
dvd.name = "DVD Video Instance"
print("video 인스턴스의 name 값은 \(video.name!)입니다.")
//video 인스턴스의 name 값은 DVD Video Instance입니다.

changeName(v: video)
print("video 인스턴스의 name 값은 \(video.name!)입니다.")
//video 인스턴스의 name 값은 Function Video Instance입니다.

인스턴스 비교

• 참조 타입이기 때문에 같은 인스턴스 비교하는 연산자 활용
  • 동일 인스턴스 인지 비교 : ===
  • 동일 인스턴스가 아닌지 비교 : !==

동일 인스턴스 참조

class VideoMode {
var interlaced = false
var frameRate = 0.0
var name: String?
}

let video = VideoMode()
let dvd = video

if (video === dvd) {
    print("video와 DVD는 동일한 인스턴스를 참조하고 있습니다.")
} else {
    print("video와 DVD는 서로 다른 인스턴스를 참조하고 있습니다.")
}

// "video와 DVD는 동일한 인스턴스를 참조하고 있습니다."

서로 다른 인스턴스 참조

class VideoMode {
var interlaced = false
var frameRate = 0.0
var name: String?
}

let video = VideoMode()
let dvd = VideoMode()

if (video === dvd) {
    print("video와 DVD는 동일한 인스턴스를 참조하고 있습니다.")
} else {
    print("video와 DVD는 서로 다른 인스턴스를 참조하고 있습니다.")
}

// "video와 DVD는 서로 다른인스턴스를 참조하고 있습니다."

Struct - 값에 의한 전달(Value Type)

• 모든 Struct Instance들은 상수나 변수에 할당될 때 복사됨.
• 따라서 변수에 대입된 기존의 Instance는 서로 독립적이다.
• Instance가 상수/변수 중 어느곳에 할당 되는가에 따라 Property값을 변경 여부가 달라진다.
  • 상수 할당 : Property 변경 불가
  • 변수 할당 : Property 변경 가능

struct Resolution {
    var width = 0
    var heigth = 0
}

let hd = Resolution(width: 1920, heigth: 1080)

var cinema = hd
cinema.width = 2048

print("hd 인스턴스의 width 값은 \(hd.width)입니다.")
//"hd 인스턴스의 width 값은 1920입니다.\n"

print("cinema 인스턴스의 width 값은 \(cinema.width)입니다.")
//"cinema 인스턴스의 width 값은 2048입니다."

인스턴스(Instance)

메모리의 공간을 할당 받는 객체

• Instance를 생성하여 Property에 접근한다.
• dot 문법(.)을 통해 Property에 접근할 수 있다.

초기화(Initialize)

• 스위프트에서 Optional로 설정되지 않은 모든 Property는 명시적으로 초기화해 주어야 한다.
• 초기화는 다음 방식으로 수행한다.
  • Property를 선언하면서 동시에 초기값을 지정.
  • 초기화 메소드 내에서 Property의 초기값을 지정.
  • 위 두 방법이 불가할 경우 Optional 타입으로 설정.

기본 초기화 구문(Initializer)

• Instance만을 생성하는 초기화 구문이다.
• 어떠한 Property도 초기화하지 않는다.
• Class의 경우 모든 Property가 선언과 동시에 초기화되어 있을 경우에만 사용할 수 있다.

// 어떠한 인자도 받지 않고 단순히 Resolution 인스턴스만 생성
let defaultRes = Resolution()

멤버 와이즈 초기화 구문(Memberwise Initializer)

• Struct는 모든 Property의 값을 인자값으로 입력받아 초기화하는 멤버와이즈 초기화 구문을 제공한다.(Class는 제공하지 않음)
• 하나의 Property만 초기화하는 구문은 제공하지 않는다.

// width와 height를 매개변수로 하여 Resolution 인스턴스 생성
let defaultRes = Resolution(width: 1024, height: 768)