11 · Sequence·Collection과 lazy

import Foundation

let bigArr = Array(0..<5_000_000)
let bigStr = String(repeating: "a", count: 5_000_000)

var t = Date()
_ = bigArr.count
print("Array.count:", Date().timeIntervalSince(t))   // 실측 ≈ 0.0000031초

t = Date()
_ = bigStr.count
print("String.count:", Date().timeIntervalSince(t))  // 실측 ≈ 0.00458초 — 약 1,500배 차이

// Dictionary는 BidirectionalCollection도 아니지만 count는 여전히 O(1)
var d = [Int: Int](minimumCapacity: 3_000_000)
for i in 0..<3_000_000 { d[i] = i }
t = Date()
_ = d.count
print("Dictionary.count:", Date().timeIntervalSince(t))  // 실측 ≈ 0.0000069초

// makeIterator()의 기본 구현은 "내가 곧 Iterator"일 때 self를 그대로 돌려준다.
// class는 참조 타입이라 매번 '같은 인스턴스'가 나가고, 그 인스턴스의 내부 상태(remaining)는
// 첫 순회에서 이미 다 소비돼버린다 — 이게 "소비형(destructive) Sequence"다.
final class NetworkPageStream: IteratorProtocol, Sequence {
    var remaining: [Int]
    init(_ values: [Int]) { remaining = values }
    func next() -> Int? {
        guard !remaining.isEmpty else { return nil }
        return remaining.removeFirst()
    }
}

let stream = NetworkPageStream([1, 2, 3])
for x in stream { print(x) }        // 1 2 3
for x in stream { print(x) }        // 아무것도 안 찍힘 — 이미 다 소비됨
// ✅ 다회 순회가 필요하다면 Sequence가 아니라 Collection을 채택해야 한다.

struct MessageRow {
    let text: String

    // ❌ 셀이 다시 그려질 때마다 O(n)으로 그래핌 경계를 다시 계산한다
    var isTooLongBad: Bool { text.count > 200 }

    // ✅ "비어있는지"만 필요하면 O(1)인 isEmpty로
    var isEmptyGood: Bool { text.isEmpty }

    // ✅ 반복 조회가 필요하면 계산 시점에 한 번만 캐시해서 들고 있는다
    let cachedCount: Int
    init(text: String) {
        self.text = text
        self.cachedCount = text.count   // 여기서 딱 한 번 O(n)
    }
}

// ✅ Collection을 채택하면 인덱스 기반 재접근·멀티패스가 '계약으로' 보장된다
struct RecentEvents: Collection {
    private var buffer: [String]
    var startIndex: Int { buffer.startIndex }
    var endIndex: Int { buffer.endIndex }
    func index(after i: Int) -> Int { buffer.index(after: i) }
    subscript(position: Int) -> String { buffer[position] }
}
// 이렇게 만들면 이 타입을 두 번, 세 번 순회해도 항상 같은 결과가 나온다는 걸
// 호출부가 컴파일러 수준의 계약으로 믿을 수 있다.

var callCount = 0
let base = [1, 2, 3, 4, 5]
let lazySeq = base.lazy.map { (x: Int) -> Int in
    callCount += 1
    return x * 2
}
_ = Array(lazySeq)               // 첫 번째 순회
print(callCount)                 // 실측: 5
_ = Array(lazySeq)               // 같은 lazySeq를 다시 순회 — 재계산!
print(callCount)                 // 실측: 10 (5가 아니라)

var evalCountLazy = 0
let lazyResult = (1...1_000_000).lazy.map { (n: Int) -> Int in
    evalCountLazy += 1
    return n * 2
}.first { $0 > 20 }
print(evalCountLazy)             // 실측: 11

var evalCountEager = 0
let eagerResult = (1...1_000_000).map { (n: Int) -> Int in
    evalCountEager += 1
    return n * 2
}.first { $0 > 20 }
print(evalCountEager)            // 실측: 1,000,000 — first(where:) 전에 map이 이미 다 끝나 있다

struct User { let id: Int; let email: String }
let users: [User] = /* 수십만 건 */ []

// ❌ filter가 조건에 맞는 전부를 배열로 만든 다음에야 first를 고른다
func findByEmailBad(_ target: String) -> User? {
    users.filter { $0.email == target }.first
}

// ✅ lazy면 email이 일치하는 첫 원소를 찾는 즉시 나머지를 보지 않는다
func findByEmailGood(_ target: String) -> User? {
    users.lazy.filter { $0.email == target }.first
}

// ❌ 이 lazy 시퀀스를 두 번 쓰면(한 번은 개수 세기, 한 번은 실제 출력) 로그도 두 번 남는다
let riskyLazy = rawEvents.lazy.map { event -> String in
    Logger.log("processing \(event)")   // 부수효과!
    return event.description
}

// ✅ 여러 번 쓸 거라면 즉시 확정해서 캐시한다 — 계산은 딱 한 번만
let processedEvents = Array(rawEvents.lazy.map { event -> String in
    Logger.log("processing \(event)")
    return event.description
})

let longString = String(repeating: "x", count: 1_000_000) + "TARGET"
let sub = longString.suffix(6)   // Substring "TARGET"

let baseP = longString.utf8.withContiguousStorageIfAvailable { Int(bitPattern: $0.baseAddress) } ?? 0
let subP  = sub.utf8.withContiguousStorageIfAvailable { Int(bitPattern: $0.baseAddress) } ?? 0

print(subP - baseP)   // 실측: 1,000,000 — "TARGET"이 시작하는 정확한 바이트 오프셋.
                      // 새로 복사된 데이터라면 이 차이는 아무 의미가 없어야 한다.

import Darwin

func residentMB() -> Double {
    var info = mach_task_basic_info()
    var count = mach_msg_type_number_t(MemoryLayout<mach_task_basic_info>.size / MemoryLayout<natural_t>.size)
    let kerr = withUnsafeMutablePointer(to: &info) {
        $0.withMemoryRebound(to: integer_t.self, capacity: Int(count)) {
            task_info(mach_task_self_, task_flavor_t(MACH_TASK_BASIC_INFO), $0, &count)
        }
    }
    guard kerr == KERN_SUCCESS else { return -1 }
    return Double(info.resident_size) / 1024 / 1024
}

func parseBigFile() -> ArraySlice<Int> {
    let wholeFile = Array(0..<60_000_000)   // "파일에서 읽은 6천만 개 레코드"라고 하자 (≈480MB)
    return wholeFile[0..<1]                  // 첫 레코드 하나만 뽑아 반환
}

print(residentMB())        // 파싱 전 ≈ 5.7MB
let firstRecord = parseBigFile()
print(residentMB())        // 파싱 후, 레코드 1개만 들고 있는데도 ≈ 463.5MB — 480MB가 그대로!

// ❌ 파싱 결과를 Substring 그대로 저장 — 원본 전체 버퍼가 계속 메모리에 남는다
struct ParsedHeaderBad {
    let title: Substring   // longString 전체 버퍼를 계속 붙든다
}

// ✅ String으로 명시 변환 — 새 작은 버퍼로 복사되어 원본과 완전히 분리된다
struct ParsedHeaderGood {
    let title: String
    init(from sub: Substring) {
        title = String(sub)   // 여기서 딱 한 번, 필요한 만큼만 복사
    }
}

let array = [10, 20, 30, 40, 50]
let slice = array[2...4]        // ArraySlice, startIndex는 0이 아니라 2

// ❌ slice[0] — "Fatal error: Index out of bounds"로 크래시(실측: Swift/SliceBuffer.swift:307)
// print(slice[0])

// ✅ 안전한 접근
print(slice[slice.startIndex])  // 30
print(slice.first ?? -1)        // 30

struct Person { let name: String; let age: Int }
var people = [
    Person(name: "Bob", age: 30),
    Person(name: "Alice", age: 30),
    Person(name: "Carol", age: 25),
]
people.sort { $0.name < $1.name }   // Alice, Bob, Carol
people.sort { $0.age < $1.age }     // 나이만 기준으로 다시 정렬

print(people.map { $0.name })
// 실측: ["Carol", "Alice", "Bob"]
// Carol(25)이 맨 앞은 당연하고, 나이가 같은 Alice·Bob 사이에서는
// 직전 이름 정렬 순서(Alice → Bob)가 그대로 유지됐다 — 안정 정렬의 증거

struct Order { let customerName: String; let priority: Int; let placedAt: Date }

// 1) 먼저 가장 낮은 우선순위 기준(접수 시각)으로 정렬
orders.sort { $0.placedAt < $1.placedAt }
// 2) 그다음 진짜 기준(priority)으로 정렬 — priority가 같은 주문끼리는
//    안정 정렬 덕분에 1단계에서 정해둔 접수 시각 순서가 그대로 유지된다
orders.sort { $0.priority > $1.priority }
// 결과: priority 내림차순, 같은 priority 안에서는 접수 시각 오름차순

let indexed = orders.enumerated().map { (index: $0.offset, order: $0.element) }
let sortedOrders = indexed.sorted {
    if $0.order.priority != $1.order.priority {
        return $0.order.priority > $1.order.priority
    }
    return $0.index < $1.index   // 동률이면 원래 순서를 명시적으로 유지
}.map { $0.order }

var nums = (0..<2_000_000).map { _ in Int.random(in: 0..<10) }
nums.sort { $0 >= $1 }   // a >= a는 항상 true — 비반사성 위반
print(nums.prefix(5))    // 실측: 크래시 없음, 그냥 내림차순으로 정렬됨

var nums: [Double] = [5, 3, 8, 1, 9, Double.nan, 2, Double.nan, 7]
nums.sort()   // Comparable의 < 를 그대로 사용. NaN과의 비교는 항상 false
print(nums)
// 실측 결과: [1.0, 3.0, 5.0, 8.0, 9.0, nan, 2.0, nan, 7.0]
// 2.0과 7.0이 9.0보다 뒤에 와 있다 — 명백히 오름차순이 아니다

var brokenAdjacent = 0
for i in 1..<nums.count where !(nums[i - 1] <= nums[i]) { brokenAdjacent += 1 }
print(brokenAdjacent)   // 실측: 4 — 인접 원소 사이 오름차순이 깨진 지점이 4군데

// ❌ 흔한 실수 — "크거나 같으면"이라는 말을 그대로 코드로 옮김
items.sort { $0.priority >= $1.priority }

// ✅ 내림차순이 목적이면 엄격 부등호의 방향만 뒤집는다
items.sort { $0.priority > $1.priority }

// ❌ NaN이 섞이면 결과가 오름차순이라는 보장이 사라진다
values.sort()

// ✅ NaN을 먼저 걸러내고, 별도로 어디에 둘지 스스로 정한다
let (nans, finite) = values.reduce(into: ([Double](), [Double]())) { acc, v in
    if v.isNaN { acc.0.append(v) } else { acc.1.append(v) }
}
let sortedValues = finite.sorted() + nans   // NaN은 맨 뒤로 몰아둔다는 규칙을 직접 명시