05 · Swift 런타임과 언어 구현

struct SPoint { var x = 0 }
final class CPoint { var x = 0 }

var sa = SPoint(); var sb = sa      // 값 복사
sb.x = 99
print(sa.x, sb.x)                   // 0 99  (독립)

let ca = CPoint(); let cb = ca      // 참조 복사(같은 객체)
cb.x = 99
print(ca.x, cb.x)                   // 99 99 (공유)
print(ca === cb)                    // true  (같은 식별자)

// MemoryLayout은 헤더를 제외한 값의 저장 크기만 잰다
print(MemoryLayout<SPoint>.size)  // 8   (Int 하나)
print(class_getInstanceSize(CPoint.self)) // 24  (16B 헤더 + Int 8)

import Foundation

// 값 타입은 ARC도, 순환 참조도, 스레드 경합도 구조적으로 없다.
// "왜 class여야 하는가"에 답할 수 없으면 struct가 맞다.

// ✅ 모델·값 객체·상태 — 전부 값 타입
struct User: Sendable, Equatable, Codable {
    let id: UUID
    var displayName: String
    var email: String
}

struct CartItem: Sendable, Equatable {
    let sku: String
    var quantity: Int
    var unitPrice: Decimal

    var subtotal: Decimal { unitPrice * Decimal(quantity) }
}

struct Cart: Sendable, Equatable {
    var items: [CartItem] = []
    var total: Decimal { items.reduce(0) { $0 + $1.subtotal } }
}

// 값 타입이라 이런 게 공짜로 따라온다
func valueTypeBenefits() {
    var a = Cart(items: [CartItem(sku: "X", quantity: 1, unitPrice: 100)])
    let snapshot = a                 // ① 스냅샷이 그냥 대입이다
    a.items[0].quantity = 5
    assert(snapshot.items[0].quantity == 1)   // ② 원본이 안 바뀐다

    // ③ Equatable·Codable·Hashable이 자동 합성된다
    // ④ 다른 스레드로 넘겨도 안전하다(Sendable)
}

// UI 상태도 값으로 두면 변경 추적과 되돌리기가 단순해진다
struct EditorState: Equatable {
    var text: String = ""
    var selection: Range<Int>? = nil
}
var undoStack: [EditorState] = []

import Foundation
import UIKit

// class를 고르는 정당한 이유는 다섯 가지뿐이다.

// ① 공유 가변 상태 — 여러 곳이 '같은 것'을 봐야 한다
final class SessionStore {
    private(set) var currentUser: User?
    func signIn(_ u: User) { currentUser = u }
}

// ② 식별자(identity) — 값이 같아도 다른 개체여야 한다
final class Connection {
    let id = UUID()
}
func identityMatters(_ a: Connection, _ b: Connection) -> Bool {
    a === b            // 값이 아니라 '그 개체인가'를 묻는다
}

// ③ deinit — 결정적 시점에 자원을 반납해야 한다
final class FileWriter {
    private let handle: FileHandle
    init(_ h: FileHandle) { handle = h }
    deinit { try? handle.close() }
}

// ④ 상속 — 프레임워크가 요구한다
final class FeedViewController: UIViewController {}   // UIKit이 class를 요구

// ⑤ Objective-C 상호운용 — @objc·KVO·NSCoding
final class LegacyBridge: NSObject {
    @objc dynamic var progress: Double = 0     // KVO 대상
}

// ✅ 상속을 안 쓸 거면 final을 붙인다 — 동적 디스패치가 정적으로 바뀐다
//    (WMO가 켜지면 컴파일러가 추론하기도 하지만, 명시가 확실하다)
final class Cache {}          // ✅
class OpenCache {}            // ❌ 이유 없이 열어 두면 최적화를 막는다

struct User { let id: UUID }

import Foundation

// 값 타입은 복사가 기본이다. 대부분은 문제가 안 되지만,
// 큰 struct를 초당 수만 번 넘기면 memcpy 비용이 실제로 보인다.

// 128바이트짜리 struct (Double 16개) — 반환·대입마다 통째로 복사된다
struct Matrix4x4 {
    var m: (Double, Double, Double, Double,
            Double, Double, Double, Double,
            Double, Double, Double, Double,
            Double, Double, Double, Double)
}

// ❌ 반복문에서 값으로 주고받기
func transformBad(_ m: Matrix4x4, by t: Matrix4x4) -> Matrix4x4 {
    m                          // 인자는 주소로 빌려 오지만(기본이 borrowing) 반환값은 통째로 복사된다
}

// ✅ ① 제자리 수정 — inout은 복사 없이 참조로 넘긴다
func transform(_ m: inout Matrix4x4, by t: Matrix4x4) {
    // m을 직접 수정
}

// ✅ ② 참조 필드를 품은 큰 struct라면 borrowing으로 ARC 트래픽을 생략시킨다
//    (Matrix4x4처럼 참조가 없는 trivial 타입은 이미 기본이 borrowing이라 효과가 없다)
func determinant(of m: borrowing Matrix4x4) -> Double { 0 }

// ✅ ③ 내부가 Array라면 COW가 알아서 완화해 준다 — 이 경우엔 걱정할 필요가 적다
struct Mesh {
    var vertices: [Double]     // 복사해도 버퍼 참조만 복사된다(O(1))
}

// 크기를 직접 확인해 감을 잡는다
func sizes() {
    print(MemoryLayout<Matrix4x4>.size)   // 128
    print(MemoryLayout<Mesh>.size)        // 8  (버퍼 참조 하나)
}

// ⚠️ "값 타입이라 복사가 비싸다"는 일반화는 틀렸다.
//    Array·String·Data 같은 표준 컬렉션은 COW라 대입 비용이 O(1)이다.
//    비싼 건 '고정 크기 페이로드가 큰' struct뿐이다.

struct Box {                 // struct지만…
    var items = NSMutableArray()   // 참조 타입 프로퍼티
}
var a = Box()
var b = a                    // Box 자체는 값 복사
b.items.add("x")             // 그러나 items는 같은 객체를 공유!
print(a.items.count)         // 1  ← value semantics가 깨졌다

// 순수 값 타입이면
struct Pure { var items: [String] = [] }  // Array는 COW 값 타입
var c = Pure(); var d = c
d.items.append("x")
print(c.items.count)         // 0  ← 독립적 (value semantics 유지)

import Foundation

// 값 의미론은 "이 값을 넘겨도 내 것이 안 바뀐다"는 보장이다.
// 그 보장이 있으면 추론 범위가 함수 안으로 줄어든다.

struct Order: Sendable, Equatable {
    let id: UUID
    var status: Status
    var items: [Item]

    enum Status: Sendable, Equatable { case draft, placed, shipped, cancelled }
    struct Item: Sendable, Equatable {
        let sku: String
        var quantity: Int
    }
}

// ✅ 변환은 '새 값을 만드는' 함수로 — 원본이 절대 안 바뀐다
extension Order {
    func placing() -> Order {
        var copy = self
        copy.status = .placed
        return copy
    }
}

// ✅ 호출자는 자기 값이 안전하다는 걸 시그니처만 보고 안다
func validate(_ order: Order) -> [String] {
    // order를 아무리 만져도(로컬 복사) 호출자 것은 그대로다
    var errors: [String] = []
    if order.items.isEmpty { errors.append("빈 주문") }
    return errors
}

// ✅ 테스트가 단순해진다 — 목이 필요 없고 값만 비교하면 된다
func test_주문_확정() {
    let draft = Order(id: UUID(), status: .draft, items: [])
    let placed = draft.placing()
    assert(draft.status == .draft)      // 원본 불변
    assert(placed.status == .placed)
}

// ✅ 동시성도 공짜로 따라온다 — 복사본을 넘기므로 공유가 없다
func process(_ orders: [Order]) async -> [Order] {
    await withTaskGroup(of: Order.self) { group in
        for o in orders { group.addTask { o.placing() } }
        var out: [Order] = []
        for await r in group { out.append(r) }
        return out
    }
}

import Foundation

// struct라도 안에 참조 타입이 있으면 그 부분은 공유된다.
// 호출자는 값처럼 믿는데 실제로는 아니므로, 가장 찾기 어려운 버그가 된다.

// ❌ 겉은 struct, 속은 공유
struct BadDocument {
    var title: String
    var pages = NSMutableArray()        // 참조 타입
}

func demonstrateBug() {
    var a = BadDocument(title: "A")
    var b = a                            // "복사"했다고 믿는다
    b.pages.add("새 페이지")
    print(a.pages.count)                 // 1 — 원본까지 바뀌었다 💥
}

// ✅ ① 순수 값 타입으로 바꾼다 (최선)
struct Document {
    var title: String
    var pages: [String] = []             // Array는 COW 값 타입
}

// ✅ ② 참조를 꼭 담아야 하면 방어적 복사로 독립성을 복원한다
struct ImageDocument {
    private var storage: NSMutableData

    init(data: NSMutableData) {
        storage = data.mutableCopy() as! NSMutableData   // 들어올 때 복사
    }

    var data: Data { storage as Data }                    // 나갈 때는 불변으로

    mutating func append(_ chunk: Data) {
        if !isKnownUniquelyReferenced(&storage) {         // COW를 직접 구현
            storage = storage.mutableCopy() as! NSMutableData
        }
        storage.append(chunk)
    }
}

// ✅ ③ 공유가 의도라면 문서화하고 이름으로 드러낸다
struct ViewModelRef {
    /// ⚠️ 공유 참조입니다. 복사해도 같은 인스턴스를 가리킵니다.
    let sharedCoordinator: Coordinator
}
final class Coordinator {}

import Foundation

// class를 써야 하는데 값처럼 다루고 싶다면, 방법은 '불변'뿐이다.

// ✅ ① 전부 let — 만들어진 뒤 아무도 못 바꾼다 → 공유해도 안전
final class Configuration: Sendable {
    let baseURL: URL
    let timeout: TimeInterval
    let headers: [String: String]

    init(baseURL: URL, timeout: TimeInterval, headers: [String: String] = [:]) {
        self.baseURL = baseURL
        self.timeout = timeout
        self.headers = headers
    }

    // ✅ 변경은 '새 인스턴스를 만드는' 메서드로 (값 타입의 mutating에 대응)
    func with(timeout: TimeInterval) -> Configuration {
        Configuration(baseURL: baseURL, timeout: timeout, headers: headers)
    }

    func adding(header key: String, _ value: String) -> Configuration {
        var h = headers; h[key] = value
        return Configuration(baseURL: baseURL, timeout: timeout, headers: h)
    }
}

// ✅ ② 불변으로 못 만들면 복사 메서드를 '명시적으로' 제공한다
final class MutableBuffer {
    private(set) var bytes: [UInt8]
    init(bytes: [UInt8]) { self.bytes = bytes }

    /// 호출자가 독립 사본을 원한다는 걸 코드에 드러낸다
    func copy() -> MutableBuffer { MutableBuffer(bytes: bytes) }

    func append(_ b: UInt8) { bytes.append(b) }
}

func useCopy(_ original: MutableBuffer) {
    let mine = original.copy()      // ✅ 의도가 호출부에 보인다
    mine.append(0)
}

// ⚠️ NSCopying 관례를 따를 수도 있지만, Swift에서는 명시적 copy() 메서드나
//    애초에 struct로 가는 편이 더 명확하다.

var a = [1, 2, 3]
var b = a
a.withUnsafeBufferPointer { print($0.baseAddress!) }  // 같은 주소
b.withUnsafeBufferPointer { print($0.baseAddress!) }  // 같은 주소 (공유)
b.append(4)
b.withUnsafeBufferPointer { print($0.baseAddress!) }  // 다른 주소 → 복사됨

// 직접 COW: 변경 직전에만 버퍼를 복제
final class Ref<T> { var value: T; init(_ v: T) { value = v } }
struct COWBox<T> {
    private var ref: Ref<T>
    init(_ v: T) { ref = Ref(v) }
    var value: T { ref.value }
    mutating func set(_ v: T) {
        if !isKnownUniquelyReferenced(&ref) { ref = Ref(ref.value) } // 공유 중이면 복제
        ref.value = v
    }
}

import Foundation

// Array.append는 amortized O(1)이지만, 용량이 찰 때마다 새 버퍼를 잡고
// 전체를 복사한다. 최종 크기를 알면 그 복사를 전부 없앨 수 있다.

// ❌ 재할당이 log n 번 일어난다 (2→4→8→16→… 실제 값은 malloc 블록에 맞춰 반올림된다)
func buildBad(_ source: [Row]) -> [ViewModel] {
    var out: [ViewModel] = []
    for r in source { out.append(ViewModel(r)) }
    return out
}

// ✅ 한 번만 할당한다
func build(_ source: [Row]) -> [ViewModel] {
    var out: [ViewModel] = []
    out.reserveCapacity(source.count)
    for r in source { out.append(ViewModel(r)) }
    return out
}

// ✅ 더 간단히 — map은 내부적으로 용량을 미리 잡는다
func buildMap(_ source: [Row]) -> [ViewModel] {
    source.map(ViewModel.init)
}

// 용량 증가를 직접 관찰해 보면 감이 온다
func observeGrowth() {
    var a: [Int] = []
    var lastCapacity = a.capacity
    for i in 0..<1000 {
        a.append(i)
        if a.capacity != lastCapacity {
            print("count \(a.count) → capacity \(a.capacity)")   // 재할당 시점
            lastCapacity = a.capacity
        }
    }
}

// ✅ Dictionary·Set도 마찬가지 — 재해시를 없앤다
func buildIndex(_ rows: [Row]) -> [String: Row] {
    var index = [String: Row](minimumCapacity: rows.count)
    for r in rows { index[r.id] = r }
    return index
}

struct Row { let id: String }
struct ViewModel { init(_ r: Row) {} }

import Foundation

// 배열을 값으로 넘기면 호출된 쪽에서 변경할 때 COW가 발동해 전체가 복사된다.
// 제자리 수정이 목적이라면 inout이 그 복사를 없앤다.

// ❌ 안에서 바꾸면 사본이 생긴다 (호출자 배열과 공유 상태였으므로)
func normalizeBad(_ values: [Double]) -> [Double] {
    var copy = values                       // 참조만 복사
    for i in copy.indices { copy[i] /= 255 } // 첫 쓰기에서 전체 복사 발생
    return copy
}

// ✅ inout — 넘기는 것 자체로는 복사가 없다
//    (다만 호출자 배열이 다른 변수와 버퍼를 공유 중이면 첫 쓰기에서 COW가 1회 일어난다)
func normalize(_ values: inout [Double]) {
    for i in values.indices { values[i] /= 255 }
}

// 사용
func useInout() {
    var samples = [Double](repeating: 128, count: 1_000_000)
    normalize(&samples)                     // 복사 0회
}

// ✅ 더 빠른 경로 — 경계 검사까지 줄인다
func normalizeFast(_ values: inout [Double]) {
    values.withUnsafeMutableBufferPointer { buf in
        for i in buf.indices { buf[i] /= 255 }
    }
}

// 복사가 실제로 일어났는지 버퍼 주소로 확인할 수 있다
func detectCopy() {
    var a = [1.0, 2.0, 3.0]
    let before = a.withUnsafeBufferPointer { $0.baseAddress }
    normalize(&a)
    let after = a.withUnsafeBufferPointer { $0.baseAddress }
    print(before == after ? "복사 없음 ✅" : "복사 발생 ❌")
}

import Foundation

// 배열을 클로저가 캡처하면 참조가 하나 더 생긴다.
// 그 뒤에 배열을 변경하면 "혼자가 아니므로" COW가 발동한다.

final class Renderer {
    private var buffer = [Float](repeating: 0, count: 1_000_000)
    private var onSnapshot: (() -> Void)?

    // ❌ 클로저가 buffer를 캡처 → 캡처 이후 '첫' 쓰기에서 전체 복사가 터진다
//    (그 뒤엔 다시 단독 소유라 제자리 수정이다)
    func setupBad() {
        onSnapshot = { [buffer] in           // 값 캡처지만 버퍼 참조는 공유된다
            print(buffer.count)
        }
    }

    func write() {
        buffer[0] = 1                        // setupBad 이후엔 여기서 4MB 복사
    }

    // ✅ 필요한 것만 캡처한다
    func setup() {
        let count = buffer.count             // 스칼라만 복사
        onSnapshot = { print(count) }        // 버퍼를 붙들지 않는다
    }

    // ✅ 스냅샷이 정말 필요하면 '그때' 명시적으로 뜬다
    func snapshotNow() -> [Float] {
        buffer                               // 이 시점에만 공유가 생긴다
    }
}

// 같은 함정: 배열을 프로퍼티에 대입해 두고 원본을 계속 쓰는 경우
final class Cache {
    var lastSnapshot: [Float] = []
    var working = [Float](repeating: 0, count: 1_000_000)

    func snapshot() { lastSnapshot = working }   // 공유 시작
    func mutate() { working[0] = 1 }             // 여기서 복사 발생 (의도된 것이면 OK)
}

// 판별법: isKnownUniquelyReferenced는 클래스에만 쓸 수 있으므로,
// 배열은 baseAddress 비교로 복사 여부를 관찰한다(디버깅 용도).

import Foundation

// Array는 NSArray와 브리징될 가능성 때문에 요소 접근에 약간의 검사가 들어간다.
// 클래스나 @objc 프로토콜 요소를 담을 때 특히 그렇다.
// ContiguousArray는 항상 연속된 네이티브 버퍼를 보장해 그 검사를 없앤다.

// ✅ 수치 연산·버퍼 처리처럼 성능이 중요한 경로
var samples = ContiguousArray<Float>(repeating: 0, count: 1_000_000)

func process(_ buffer: inout ContiguousArray<Float>) {
    buffer.withUnsafeMutableBufferPointer { buf in
        for i in buf.indices { buf[i] *= 0.5 }
    }
}

// ⚠️ 값 타입(Int·Float·struct)만 담는 Array는 이미 네이티브 버퍼를 쓴다.
//    그래서 이 경우 차이가 거의 없다 — 실제 이득은 '클래스 요소'를 담을 때다.
final class Node {}
var nodes = ContiguousArray<Node>()      // ✅ 브리징 검사 제거 효과가 있다

// ⚠️ 대가: NSArray로 브리징되지 않는다. Objective-C API에 넘겨야 하면 못 쓴다.
func needsBridging(_ array: [Node]) {
    let nsArray = array as NSArray       // ContiguousArray는 이게 안 된다
    _ = nsArray
}

// 판단 순서
//   ① 먼저 측정한다 — 대부분의 코드에서 차이가 없다
//   ② 프로파일러가 배열 접근을 핫스팟으로 지목했고
//   ③ 요소가 클래스/existential이며
//   ④ ObjC 브리징이 필요 없을 때
//   → 그때 ContiguousArray로 바꾼다

final class Downloader {
    var onDone: (() -> Void)?

    func start() {
        onDone = { self.finish() }        // self ↔ onDone 사이클
    }

    func startSafe() {                    // 끊기
        onDone = { [weak self] in
            guard let self else { return }
            self.finish()
        }
    }

    func finish() {}
    deinit { print("deinit") }            // 사이클이면 절대 안 찍힘
}

import Foundation

final class FeedLoader {
    private var completion: (([Item]) -> Void)?
    private var items: [Item] = []

    // ❌ self가 completion을 보유 + completion이 self를 캡처 = 순환
    func loadBad() {
        completion = { newItems in
            self.items = newItems            // 💥 영구 누수
        }
    }

    // ✅ 저장되고 나중에 실행되는 클로저 → weak + guard
    func load() {
        completion = { [weak self] newItems in
            guard let self else { return }   // 이미 해제됐으면 조용히 종료
            self.items = newItems
            self.notify()
        }
    }

    // ✅ 여러 번 쓰는 self는 guard let으로 한 번만 풀어 쓴다
    //    (self?.a, self?.b 를 반복하면 그 사이에 nil이 될 수도 있다)
    func loadDetailed() {
        api.fetch { [weak self] result in
            guard let self else { return }
            switch result {
            case .success(let items):
                self.items = items
                self.notify()                // ✅ 여기까지 self가 살아 있음이 보장된다
            case .failure(let error):
                self.handle(error)
            }
        }
    }

    private func notify() {}
    private func handle(_ e: Error) {}
    private let api = API()
}

struct Item {}
struct API {
    func fetch(_ done: @escaping (Result<[Item], Error>) -> Void) {}
}

import Foundation

// unowned는 언랩 비용이 없고 의도(“얘는 나보다 오래 산다”)를 코드로 드러낸다.
// 대신 그 가정이 깨지면 그 자리에서 crash다.

// ✅ 정당한 경우 — 소유 방향이 한쪽으로 고정돼 있다
final class Player {
    private(set) var tracks: [Track] = []
    func add(_ title: String) { tracks.append(Track(title: title, player: self)) }
}

final class Track {
    let title: String
    unowned let player: Player      // ✅ Player가 Track을 소유한다. 역은 불가능.

    init(title: String, player: Player) {
        self.title = title
        self.player = player
    }
}

// ✅ self가 소유하고 self보다 오래 못 사는 클로저
final class Timerish {
    private var tick: (() -> Void)?

    func start() {
        tick = { [unowned self] in       // tick은 self의 프로퍼티 → self보다 오래 못 산다
            self.onTick()
        }
    }
    private func onTick() {}
}

// ❌ 정당하지 않은 경우 — 수명이 외부 요인에 달려 있다
final class Screen {
    func setupCrashy(_ session: Session) {
        session.onExpire = { [unowned self] in   // 💥 Screen이 먼저 닫힐 수 있다
            self.reload()
        }
    }
    func setupSafe(_ session: Session) {
        session.onExpire = { [weak self] in      // ✅
            self?.reload()
        }
    }
    private func reload() {}
}
final class Session { var onExpire: (() -> Void)? }

// 자문할 것: "이 참조가 쓰이는 시점에 대상이 해제됐을 시나리오를 하나라도 그릴 수 있나?"
// 하나라도 그려지면 weak다.

import Foundation

final class Report {
    private var rows: [Int] = []
    private var total = 0

    // ❌ 동기·비저장 클로저에 weak를 붙이면 얻는 것 없이 잃기만 한다
    func computeBad() {
        rows.forEach { [weak self] row in
            self?.total += row               // 옵셔널 체이닝만 늘어난다
        }
    }

    // ✅ map·filter·forEach·sorted 등은 non-escaping이라 사이클이 불가능하다
    func compute() {
        rows.forEach { row in
            self.total += row                // 안전하다
        }
        let sorted = rows.sorted { self.weight($0) < self.weight($1) }
        _ = sorted
    }

    // ❌ 더 나쁜 경우: 반드시 실행돼야 하는 작업에 weak를 걸면
    //    self가 마지막 참조일 때 작업이 통째로 건너뛰어진다
    func saveBad(on queue: DispatchQueue) {
        queue.async { [weak self] in
            self?.flushToDisk()              // self가 nil이면 저장이 사라진다
        }
    }

    // ✅ 이 작업이 끝날 때까지 살아 있어야 한다면 strong 캡처가 '옳은 선택'이다
    func save(on queue: DispatchQueue) {
        queue.async {
            self.flushToDisk()               // 의도적으로 수명을 연장한다
        }
    }

    private func weight(_ i: Int) -> Int { i }
    private func flushToDisk() {}
}

// 판단 기준은 "weak가 안전해 보인다"가 아니라
// "self가 이 클로저를 보유해서 순환이 생기는가"다.

import Foundation

final class Uploader {
    private var completion: ((Result<URL, Error>) -> Void)?
    private var progress: ((Double) -> Void)?

    func upload(_ data: Data,
                onProgress: @escaping (Double) -> Void,
                completion: @escaping (Result<URL, Error>) -> Void) {
        self.progress = onProgress
        self.completion = completion
        start(data)
    }

    private func finish(_ result: Result<URL, Error>) {
        // ✅ 먼저 지역 변수로 옮기고 프로퍼티를 비운다
        //    (콜백 안에서 다시 upload를 부를 수 있으므로 순서가 중요하다)
        let done = completion
        completion = nil
        progress = nil

        done?(result)      // ✅ 클로저가 캡처한 것들이 여기서 해제된다
    }

    // ❌ 비우지 않으면 클로저가 캡처한 객체들이 Uploader 수명 내내 살아 있다
    private func finishLeaky(_ result: Result<URL, Error>) {
        completion?(result)
        // completion이 그대로 남아 캡처한 뷰컨트롤러·이미지가 계속 붙들린다
    }

    private func start(_ d: Data) {}
}

// ✅ 애초에 async/await로 바꾸면 저장할 클로저 자체가 없어진다
final class ModernUploader {
    func upload(_ data: Data) async throws -> URL {
        try await perform(data)     // 완료 후 아무것도 남지 않는다
    }
    private func perform(_ d: Data) async throws -> URL { URL(fileURLWithPath: "/") }
}

// ⚠️ 진행률처럼 여러 번 부르는 콜백은 '완료 시점'에 비운다.
//    한 번만 부르는 completion과 수명 관리가 다르다.

var handlers: [() -> Void] = []

func nonEscaping(_ f: () -> Void) {
    handlers.append(f)   // ❌ 컴파일 에러: non-escaping 파라미터는 저장 불가
    f()                  // ✅ 즉시 호출만 가능
}

func escaping(_ f: @escaping () -> Void) {
    handlers.append(f)   // ✅ 저장 가능 → f가 캡처한 것들이 계속 살아있음
}

import Foundation

// @escaping은 호출자에게 "캡처한 것들의 수명을 관리하라"는 제약을 강제하고,
// 컴파일러에게는 힙 박싱·ARC를 요구한다. 기본값(non-escaping)이 더 싸다.

// ✅ 즉시 실행하고 끝 — @escaping 불필요 (기본값)
func withTransaction<T>(_ body: () throws -> T) rethrows -> T {
    begin()
    defer { commit() }
    return try body()          // 함수가 끝나기 전에 반드시 실행된다
}

// ✅ 버퍼 접근처럼 스코프가 명확한 것도 non-escaping
func withBuffer<T>(count: Int,
                   _ body: (inout UnsafeMutableBufferPointer<UInt8>) -> T) -> T {
    var storage = [UInt8](repeating: 0, count: count)
    return storage.withUnsafeMutableBufferPointer(body)   // 클로저가 inout을 받는다
}

// ❌ 습관적으로 @escaping을 붙이면 최적화 기회를 잃는다
func withTransactionBad<T>(_ body: @escaping () -> T) -> T {
    body()                     // 저장하지도 않으면서 힙 박싱 비용만 진다
}

// ✅ 정말 필요한 경우: 저장하거나, 비동기로 나중에 부르거나
final class EventBus {
    private var handlers: [(Event) -> Void] = []

    func subscribe(_ handler: @escaping (Event) -> Void) {   // ✅ 저장한다
        handlers.append(handler)
    }
}

func loadLater(_ completion: @escaping (Data) -> Void) {     // ✅ 나중에 부른다
    DispatchQueue.global().async { completion(Data()) }
}

// 판별: 클로저를 (1) 프로퍼티/배열에 저장하거나 (2) 다른 escaping 클로저로 넘기거나
//       (3) 함수 반환 후에 부른다 → 셋 중 하나면 @escaping. 아니면 붙이지 않는다.

struct Event {}
func begin() {}; func commit() {}

import Foundation

final class DownloadTask {
    private var onComplete: ((Data) -> Void)?
    private var onProgress: ((Double) -> Void)?

    func start(onProgress: @escaping (Double) -> Void,
               onComplete: @escaping (Data) -> Void) {
        self.onProgress = onProgress
        self.onComplete = onComplete
    }

    private func complete(_ data: Data) {
        let handler = onComplete
        clearHandlers()                 // ✅ 먼저 비우고
        handler?(data)                  // ✅ 그다음 호출 (재진입 안전)
    }

    private func clearHandlers() {
        onComplete = nil
        onProgress = nil
    }

    deinit { clearHandlers() }
}

// 호출부 — self 캡처는 weak로
final class DownloadScreen {
    private let task = DownloadTask()
    private var received: Data?

    func begin() {
        task.start(
            onProgress: { [weak self] p in self?.updateBar(p) },
            onComplete: { [weak self] data in
                guard let self else { return }
                self.received = data
                self.render()
            }
        )
    }

    private func updateBar(_ p: Double) {}
    private func render() {}
}

// ⚠️ 두 방향을 모두 챙겨야 한다:
//    · 호출부: 클로저가 self를 붙들지 않게 (weak)
//    · 소유자: 클로저가 캡처한 것을 오래 붙들지 않게 (발화 후 nil)

import Foundation

// completion 저장·nil 처리·[weak self]·순환 검토가 전부 사라진다.

// ❌ 콜백 기반 — 중첩되면 에러 처리가 흩어지고 수명 관리가 복잡해진다
final class OldFlow {
    func load(completion: @escaping (Result<Profile, Error>) -> Void) {
        api.token { [weak self] tokenResult in
            guard let self else { return }
            switch tokenResult {
            case .failure(let e): completion(.failure(e))
            case .success(let token):
                self.api.profile(token) { profileResult in
                    completion(profileResult)
                }
            }
        }
    }
    private let api = API()
}

// ✅ async/await — 저장할 클로저가 없으니 순환도, 비우기도 없다
final class Flow {
    private let api = API()

    func load() async throws -> Profile {
        let token = try await api.token()
        return try await api.profile(token)
    }
}

// ✅ 취소도 구조적으로 따라온다
@MainActor
final class ProfileScreen {
    private var loadTask: Task<Void, Never>?
    private let flow = Flow()

    func onAppear() {
        loadTask = Task {
            do { render(try await flow.load()) }
            catch is CancellationError { }
            catch { showError(error) }
        }
    }

    func onDisappear() { loadTask?.cancel() }   // 화면을 닫으면 요청도 끝난다

    private func render(_ p: Profile) {}
    private func showError(_ e: Error) {}
}

struct Profile {}
struct API {
    func token(_ done: @escaping (Result<String, Error>) -> Void) {}
    func profile(_ t: String, _ done: @escaping (Result<Profile, Error>) -> Void) {}
    func token() async throws -> String { "" }
    func profile(_ t: String) async throws -> Profile { Profile() }
}

MemoryLayout<Int>.size        // 8
MemoryLayout<Int?>.size       // 9   (여분 없음 → 태그 1B 추가)
MemoryLayout<Int?>.stride     // 16  (정렬 때문)

MemoryLayout<UInt8>.size      // 1
MemoryLayout<UInt8?>.size     // 2   (256패턴 다 씀 → 태그 필요)

MemoryLayout<Bool>.size       // 1
MemoryLayout<Bool?>.size      // 1   (Bool은 2~255가 여분 → 태그 재활용)
MemoryLayout<Bool??>.size     // 1   (중첩해도 여분이 남아 안 커짐)

class C {}
MemoryLayout<C>.size          // 8
MemoryLayout<C?>.size         // 8   (널 포인터 0x0을 .none으로 재활용)

import Foundation

// Optional은 "값이 없을 수 있다"를 뜻한다. "실패했다"가 아니다.
// 실패를 nil로 뭉개면 호출자가 원인을 알 수 없고, 로깅도 불가능해진다.

// ❌ 실패 원인이 전부 사라진다
func parseBad(_ json: Data) -> User? {
    try? JSONDecoder().decode(User.self, from: json)
}
// 호출자: 네트워크 문제인지, 스키마 불일치인지, 빈 데이터인지 알 수 없다

// ✅ 실패는 throws로 — 원인이 타입으로 전달된다
func parse(_ json: Data) throws -> User {
    try JSONDecoder().decode(User.self, from: json)
}

// ✅ 진짜 부재만 Optional
struct User: Decodable {
    let id: UUID
    let email: String
    let nickname: String?        // ✅ 닉네임은 '설정 안 했을' 수 있다 — 진짜 부재
    let deletedAt: Date?         // ✅ 삭제되지 않았으면 없는 게 맞다
}

// ✅ 부재와 실패가 함께 있으면 둘을 구분해 표현한다
enum FetchResult {
    case found(User)
    case notFound                // 부재 (404) — 정상 흐름
}

func fetch(id: UUID) async throws -> FetchResult {
    // 네트워크·파싱 실패는 throw, "그런 사용자 없음"은 .notFound
    .notFound
}

// ✅ 컬렉션에서는 빈 컬렉션이 nil보다 낫다
struct Feed {
    var items: [Item] = []       // ✅ 없으면 빈 배열
    // var items: [Item]?        // ❌ nil과 []를 구분할 이유가 대부분 없다
}
struct Item {}

import Foundation
import UIKit

// !는 "여기서 nil이면 프로그래머 오류다"라는 선언이다.
// 그 판단의 근거를 코드에 남겨야 나중에 검증할 수 있다.

// ✅ ① 근거가 명확한 경우 — 앱 번들에 반드시 있는 리소스
func loadSchema() -> Data {
    let url = Bundle.main.url(forResource: "schema", withExtension: "json")!
    // 근거: 빌드 페이즈에 포함된 리소스. 없으면 빌드 구성 오류이므로 즉시 실패가 옳다.
    return try! Data(contentsOf: url)
}

// ✅ ② precondition으로 이유를 명시하면 실패 시 원인이 바로 보인다
func configure(_ tableView: UITableView?) {
    precondition(tableView != nil, "IB 아웃렛 연결 누락: tableView")
    tableView!.dataSource = nil
}

// ✅ ③ 컴파일 타임 상수처럼 명백한 경우
let apiBase = URL(string: "https://api.example.com")!   // 리터럴이라 실패 불가

// ❌ 근거 없는 강제 언래핑 — 런타임에 사용자 데이터에 따라 nil이 될 수 있다
func avatarBad(_ user: User) -> URL {
    URL(string: user.avatarURLString)!      // 💥 서버가 빈 문자열을 주면 크래시
}

// ✅ 외부 입력은 반드시 안전하게 처리한다
func avatar(_ user: User) -> URL? {
    URL(string: user.avatarURLString)
}

// ✅ 기본값이 있으면 nil 병합이 가장 읽기 쉽다
func avatarOrPlaceholder(_ user: User) -> URL {
    URL(string: user.avatarURLString) ?? placeholderURL
}

struct User { let avatarURLString: String }
let placeholderURL = URL(string: "https://example.com/placeholder.png")!

import UIKit

// IUO는 "선언은 옵셔널이지만 쓸 때는 아닌 척한다"는 타협이다.
// 정당한 이유는 사실상 둘뿐이다.

// ✅ ① IBOutlet — 뷰 로드 전에는 nil, 로드 후에는 항상 존재
final class ProfileViewController: UIViewController {
    @IBOutlet private var nameLabel: UILabel!      // 프레임워크 계약
    @IBOutlet private var avatarView: UIImageView!
}

// ✅ ② 2단계 초기화 — 자기 참조가 필요해 init에서 못 채우는 경우
final class Coordinator {
    private var router: Router!                     // init 후에 채운다

    init() {
        router = Router(coordinator: self)          // self를 넘겨야 해서 여기서
    }
}
final class Router {
    unowned let coordinator: Coordinator
    init(coordinator: Coordinator) { self.coordinator = coordinator }
}

// ❌ 그 외에는 지양 — "나중에 채울게"는 대부분 설계로 해결된다
final class BadViewModel {
    var user: User!                                 // 언제 채워지는지 타입이 말해주지 않는다
    func render() { print(user.name) }              // 💥 순서가 어긋나면 크래시
}

// ✅ 생성자 주입으로 바꾸면 컴파일러가 순서를 보장한다
final class ViewModel {
    let user: User                                  // 항상 존재한다
    init(user: User) { self.user = user }
    func render() { print(user.name) }
}

// ✅ 정말 나중에 오는 값이면 진짜 Optional로 두고 명시적으로 다룬다
final class HonestViewModel {
    private(set) var user: User?
    func render() {
        guard let user else { return showPlaceholder() }
        print(user.name)
    }
    private func showPlaceholder() {}
}

struct User { let name: String }

import Foundation

// Optional<Optional<T>>는 "없음"이 두 층이라 조건 판정이 어긋나기 쉽다.

// ① 가장 흔한 발생 지점: 값이 Optional인 딕셔너리
let settings: [String: String?] = ["nickname": nil, "theme": "dark"]

func nestedExample() {
    let a = settings["nickname"]        // String?? — 키는 있고 값이 nil
    let b = settings["missing"]         // String?? — 키 자체가 없음
    // 둘 다 "nil처럼" 보이지만 의미가 다르다

    print(a == nil)                     // false — 키가 있으므로 바깥은 non-nil
    print(b == nil)                     // true

    // ✅ 한 겹으로 평탄화한다
    let flat = settings["nickname"] ?? nil       // String?
    _ = flat
}

// ② try?가 Optional을 반환하는 함수를 감쌀 때
func find(_ id: String) throws -> User? { nil }

func tryExample() throws {
    let nested = try? find("x")         // User? — SE-0230(Swift 5)부터 try?는 겹을 더 씌우지 않는다
                                        //         대신 throw든 '못 찾음'이든 똑같이 nil이라 원인 구분이 불가능해진다
    let flat = try? find("x") ?? nil    // ✅ User?
    _ = (nested, flat)
}

// ③ map/flatMap 혼동
func mapExample() {
    let raw: String? = "42"
    let mapped = raw.map { Int($0) }        // Int?? — map은 한 겹 더 씌운다
    let flatMapped = raw.flatMap { Int($0) } // ✅ Int?
    _ = (mapped, flatMapped)
}

// ✅ 애초에 값에 Optional을 넣지 않는 설계가 가장 깔끔하다
enum Setting {
    case unset                  // 명시적으로 "설정 안 함"
    case value(String)
}
let betterSettings: [String: Setting] = ["nickname": .unset]

struct User {}

protocol Shape { func area() -> Double }

// 제네릭: 컴파일 타임에 T 확정, 특수화 시 정적 디스패치·박싱 없음
func totalG<S: Shape>(_ shapes: [S]) -> Double { shapes.reduce(0) { $0 + $1.area() } }

// existential: 이종 컬렉션 가능, 동적 디스패치 + 박싱
func totalE(_ shapes: [any Shape]) -> Double { shapes.reduce(0) { $0 + $1.area() } }

print(MemoryLayout<any Shape>.size)   // 40 (5 word)

import Foundation

protocol Shape {
    func area() -> Double
    func scaled(by f: Double) -> Self      // Self 반환 — any Shape로도 호출은 되지만(SE-0309)
                                           // 결과가 any Shape로 지워져 구체 타입이 사라진다
}

struct Circle: Shape {
    var radius: Double
    func area() -> Double { .pi * radius * radius }
    func scaled(by f: Double) -> Circle { Circle(radius: radius * f) }
}

// ✅ 제네릭 — 구체 타입 정보가 컴파일 타임에 유지된다
func totalArea<S: Shape>(_ shapes: [S]) -> Double {
    shapes.reduce(0) { $0 + $1.area() }
    // 특수화되면 area()가 정적 디스패치·인라인된다. 박싱도 없다.
}

// ✅ Self 요구가 있는 API는 제네릭이라야 성립한다
func scaleAll<S: Shape>(_ shapes: [S], by f: Double) -> [S] {
    shapes.map { $0.scaled(by: f) }        // 반환 타입이 S로 보존된다
}
// func scaleAllAny(_ s: [any Shape]) -> [any Shape]  ← Self 정보가 사라져 불편해진다

// ✅ 타입 관계를 API에 드러낼 수 있다
func firstMatching<S: Shape>(_ shapes: [S], where p: (S) -> Bool) -> S? {
    shapes.first(where: p)                 // 반환도 S — 호출부가 구체 타입을 그대로 받는다
}

// 호출부에서 타입이 보존되는 걸 확인
func usage() {
    let circles = [Circle(radius: 1), Circle(radius: 2)]
    let bigger: [Circle] = scaleAll(circles, by: 2)   // ✅ [Circle]로 돌아온다
    _ = bigger
}

// ⚠️ 제네릭의 한계: 하나의 배열에 서로 다른 구체 타입을 담을 수 없다.
//    [S]는 전부 같은 S여야 한다. 이종이 필요하면 any로 간다.

import Foundation

// 제네릭 특수화는 사용된 타입마다 기계어를 복제한다. 런타임은 빨라지지만
// 바이너리가 커지고, 커진 __TEXT는 콜드 스타트 페이지 폴트로 돌아온다.

protocol Codec { func encode() -> Data }

// ❌ 큰 함수를 제네릭으로 두면 타입 수만큼 복제된다
func processBad<C: Codec>(_ items: [C]) -> Data {
    var out = Data()
    // … 수백 줄의 로직 …
    for i in items { out.append(i.encode()) }
    return out
}
// Codec 구현이 20개면 이 수백 줄이 20벌 생길 수 있다

// ✅ 얇은 제네릭 껍데기 + 두꺼운 비제네릭 코어
func process<C: Codec>(_ items: [C]) -> Data {
    processCore(items.map { $0.encode() })     // 껍데기만 복제된다
}

private func processCore(_ encoded: [Data]) -> Data {
    var out = Data()
    // … 수백 줄의 로직 … (한 벌만 존재)
    for d in encoded { out.append(d) }
    return out
}

// ✅ 호출 빈도가 낮은 넓은 API는 일부러 existential로 경계를 둔다
func configure(_ codec: any Codec) {           // 코드 1벌
    _ = codec.encode()
}

// ✅ 특수화를 명시적으로 막을 수도 있다(라이브러리 경계에서)
// ⚠️ @inline(never)는 인라이닝만 막을 뿐 특수화는 못 막는다 — SIL에 specialized 심볼이 그대로 생긴다.
//    코드 복제를 줄이려면 위처럼 '얇은 껍데기 + 비제네릭 코어'로 쪼개거나 파라미터를 any로 받는다.
@inline(never)
func rarelyCalled<C: Codec>(_ c: C) -> Data { c.encode() }

/*  확인 방법 — 바이너리에서 특수화된 심볼을 센다
      nm -gU MyApp | xcrun swift demangle | grep 'specialized' | wc -l
      또는 Xcode → Product → Perform Action → Assemble 로 확인

    판단: 런치 시간·바이너리 크기가 문제로 잡히기 전까지는
          제네릭을 쓰는 게 맞다. 이건 '문제가 생겼을 때의 처방'이다.        */

import Foundation

protocol Renderer {
    func render(_ item: Item) -> Layer
}

struct Item {}; struct Layer {}

// existential 비용 세 가지
//   ① witness table을 통한 동적 디스패치 (인라인 불가)
//   ② 페이로드가 3워드 초과면 힙 박싱 + ARC
//   ③ 위 둘 때문에 컴파일러 최적화가 대부분 막힌다

// ❌ 프레임마다 도는 경로에서 any
func renderFrameBad(_ items: [Item], with renderer: any Renderer) -> [Layer] {
    items.map { renderer.render($0) }      // 매 호출이 동적 디스패치
}

// ✅ 제네릭으로 바꾸면 특수화 후 정적 디스패치·인라인이 가능해진다
func renderFrame<R: Renderer>(_ items: [Item], with renderer: R) -> [Layer] {
    items.map { renderer.render($0) }
}

// ✅ some 파라미터는 위와 같은 의미의 축약형이다
func renderFrameShort(_ items: [Item], with renderer: some Renderer) -> [Layer] {
    items.map { renderer.render($0) }
}

// ✅ 이종이 꼭 필요하면 '루프 밖'에서 한 번만 existential을 푼다
func renderMixed(_ items: [Item], renderers: [any Renderer]) -> [Layer] {
    renderers.flatMap { renderer in
        renderFrame(items, with: renderer)   // 여기서 제네릭으로 넘어간다
    }
}

// existential 크기를 직접 확인 — 3워드 인라인 버퍼 + 메타데이터 + witness table
func layout() {
    print(MemoryLayout<any Renderer>.size)   // 40 = 5워드
}

// 판단: 초당 수천 번 이상 도는 경로만 신경 쓴다.
//       설정·초기화처럼 드물게 도는 곳에서는 any가 훨씬 읽기 쉽다.

protocol Animal { func sound() -> String }
struct Dog: Animal { func sound() -> String { "woof" } }
struct Cat: Animal { func sound() -> String { "meow" } }

// some: 반환 타입이 하나로 고정되어야 함
func makeOne() -> some Animal { Dog() }        // OK
// func broken(_ f: Bool) -> some Animal {     // ❌ 두 구체 타입 반환 불가
//     f ? Dog() : Cat()
// }

// any: 서로 다른 타입을 한 배열에
let zoo: [any Animal] = [Dog(), Cat()]         // OK (이종)
print(zoo.map { $0.sound() })                  // ["woof", "meow"]

print(MemoryLayout<any Animal>.size)           // 40 (existential 박스)

import Foundation

protocol Store {
    associatedtype Value
    func load() -> Value
}

struct MemoryStore: Store {
    func load() -> Int { 42 }
}

// ✅ 파라미터 위치의 some — 제네릭의 문법 설탕이다
//    (의미는 같지만 호출부에서 타입 인자를 명시적으로 지정할 수 없고, 가변 인자 위치에는 못 쓴다)
func read(from store: some Store) {
    _ = store.load()
}
// 위는 func read<S: Store>(from store: S) 와 같다

// ✅ associatedtype이 있는 프로토콜은 any로 쓰기가 까다롭다 — some이 자연스럽다
// func readAny(from store: any Store) { _ = store.load() }   // Value 타입을 알 수 없다

// ✅ 반환 위치의 some — 구현부가 타입을 정하고 이름만 감춘다
func makeStore() -> some Store {
    MemoryStore()          // 호출자는 구체 타입을 모르지만 컴파일러는 안다
}

func usage() {
    let s = makeStore()
    let v = s.load()       // ✅ Int로 정확히 추론된다 (타입 관계 보존)
    _ = v
}

// ✅ SwiftUI가 이 패턴의 대표 사례다
//    body의 실제 타입은 VStack<TupleView<(Text, Divider)>> 같은 거대한 타입이지만
//    프레임워크는 그걸 알 필요가 없고, 안정적인 단일 타입이라 diffing이 가능하다

// 비용: 특수화되면 정적 디스패치이고 박싱이 없다(특수화는 최적화일 뿐 보장은 아니다).

import Foundation

protocol Plugin {
    var name: String { get }
    func run()
}

struct AnalyticsPlugin: Plugin {
    let name = "analytics"
    func run() {}
}
struct CrashPlugin: Plugin {
    let name = "crash"
    func run() {}
}

// ✅ 서로 다른 구체 타입을 한 컬렉션에 담아야 한다 → any
let plugins: [any Plugin] = [AnalyticsPlugin(), CrashPlugin()]

func runAll() {
    for p in plugins { p.run() }
}

// ✅ 런타임에 타입이 결정되는 팩토리 반환도 any
func makePlugin(named name: String) -> any Plugin {
    name == "analytics" ? AnalyticsPlugin() : CrashPlugin()
    // some으로는 불가능하다 — 반환 타입이 하나로 고정되지 않는다
}

// ✅ 저장 프로퍼티로 여러 구현을 갈아 끼워야 할 때
final class PluginHost {
    var active: (any Plugin)?          // 런타임에 교체된다
}

// ❌ 구현이 하나뿐인데 any를 쓰는 것 — 비용만 내고 얻는 게 없다
struct OnlyOne: Plugin { let name = "only"; func run() {} }
func badUsage(_ p: any Plugin) {}      // 구현이 하나면 구체 타입이 낫다
func goodUsage(_ p: OnlyOne) {}

// ✅ any를 받되 내부에서 제네릭으로 넘겨 비용을 한 번만 치르는 패턴
func process(_ plugins: [any Plugin]) {
    for p in plugins { processOne(p) }
}
private func processOne(_ p: some Plugin) {   // 박스를 매번 열지는 않지만, 구체 타입이 런타임에만 정해져 특수화는 안 되고 호출은 여전히 witness table을 탄다
    p.run()
}

import SwiftUI

// SwiftUI의 body는 반드시 some View다 — 이유가 성능과 직결된다.
// 프레임워크가 '안정적인 단일 타입'을 알아야 diffing이 가능하기 때문이다.

struct ProfileView: View {
    let user: User

    // ✅ some View — 구체 타입은 거대하지만 하나로 고정된다
    var body: some View {
        VStack(alignment: .leading, spacing: 12) {
            Text(user.name).font(.headline)
            Text(user.email).foregroundStyle(.secondary)
            Divider()
        }
    }
}

// ❌ AnyView로 감싸면 타입이 지워져 (참고: var body: any View는 애초에 컴파일되지 않는다) diffing이 무력해지고
//    매 갱신마다 뷰를 새로 만들게 된다
struct BadView: View {
    var body: some View {
        AnyView(Text("느림"))       // 꼭 필요할 때만
    }
}

// ✅ 조건 분기는 AnyView 대신 @ViewBuilder로 — 타입이 보존된다
struct ConditionalView: View {
    let isLoggedIn: Bool

    var body: some View {
        if isLoggedIn {
            Text("환영합니다")
        } else {
            Button("로그인") {}
        }
        // @ViewBuilder가 _ConditionalContent<Text, Button>으로 묶어 준다
    }
}

// ✅ 재사용 컴포넌트도 some으로 반환한다
@ViewBuilder
func badge(_ count: Int) -> some View {
    if count > 0 {
        Text("\(count)").padding(4).background(.red).clipShape(Circle())
    }
}

// AnyView가 정당한 경우: 런타임에 완전히 다른 뷰 트리를 골라야 하고
// 그 종류를 컴파일 타임에 열거할 수 없을 때(플러그인 시스템 등)

struct User { let name: String; let email: String }