16. Ringkasan & Decision Guide

Skenario	Rekomendasi
Perlu kirim non-Sendable ke background task	Region-based isolation — pastikan tidak ada akses setelah transfer
Fungsi yang "menerima ownership" non-Sendable	Gunakan `sending` parameter
Resource butuh serial access, independen dari main thread	Custom global actor dengan `@globalActor`
Thread-safe tapi Swift tidak bisa buktikannya	`nonisolated(unsafe)` — dengan dokumentasi jelas mengapa aman
Migrasi bertahap dari codebase lama	`@preconcurrency` sebagai solusi sementara
Actor dengan operasi multi-step yang kompleks	State machine eksplisit — hindari mutable state di antara `await`
Concurrent identical requests	Deduplication via task tracking sebelum suspension point
Protocol dari library lama belum concurrent-safe	`@preconcurrency` conformance + `@unchecked Sendable` jika diperlukan
Closure tidak berperilaku seperti yang diharapkan	Audit: `Task {}` vs `Task.detached {}`, `@Sendable` vs non-Sendable
Isolation error yang membingungkan	Gunakan checklist debugging di Seksi 12

Mental Model untuk Swift Isolation

swift
Pertanyaan saat mendesain:
1. "Siapa yang memiliki data ini?" → Tentukan isolation domain
2. "Kapan data ini bisa diakses bersamaan?" → Identifikasi suspension points
3. "Data ini perlu berpindah domain?" → Gunakan Sendable atau region analysis
4. "Ada multiple step dengan await?" → Pikirkan re-entrancy, gunakan state machine

Penguasaan Swift Isolation bukan tentang menghafal aturan — melainkan tentang membangun intuisi tentang kapan data bisa diakses secara bersamaan. Setiap await adalah peluang untuk bertanya: "Apa yang bisa berubah saat code ini suspended?"

Langkah selanjutnya: swift-concurrency-complete.md untuk gambaran komprehensif semua API Swift Concurrency, dan swift6-synchronization.md untuk low-level primitif seperti Mutex dan Atomic yang melengkapi isolation model ini.