Swift 6.3 Geçişi: Actor Isolation Uyarıları ve Kaçış Yolları

Swift 6.2'de sorunsuz derlenen bir proje, tek satır değiştirmeden Swift 6.3'e geçtiğinde actor isolation uyarısı fırlatmaya başlarsa şaşırma — bu tesadüf değil. Swift 6.3, actor isolation'da yeni bir dil kuralı ya da varsayılan getirmedi; buna karşın 6.2'de sessizce derlenen bazı kalıplar 6.3'te uyarı üretmeye başlıyor — aşağıda göreceğin belgelenmiş vakada bu uyarının kökü yeni bir kural değil, region isolation analizinin muhafazakâr davranışı. Bu yazı genel bir "strict concurrency nedir" anlatımı değil; doğrudan 6.2 → 6.3 sürüm deltasında hangi kod kalıplarının kırıldığını, gerçek hata mesajlarıyla ve gerçek kaçış yollarıyla gösteriyor.

💡 Pro Tip: Bir kod parçasının isolated mı nonisolated mı olduğu, imzasının bir parçasıdır — bunu değiştirmek neredeyse her zaman kaynak-kırıcı bir değişikliktir; sürüm yükseltirken en çok buradan vuruluyorsun.

İçindekiler

• Bugünün gerçeği: 6.3.3 yayında, 6.4 yolda
• 6.2 → 6.3 dil değişiklikleri özeti
• Belgelenmiş vaka: `@Sendable` × `@escaping` isolation uyarısı
• Kaçış kapıları: `nonisolated(unsafe)` ve `@preconcurrency`
• Aynı vakanın kökü: region isolation analizi
• Uyarıları hataya çevirmeden aşamalı geçiş
• SPM paketlerinde sürüm çakışması yönetimi
• Swift 6.4'te ne bekleniyor
• SSS
• Swift 6.2'den 6.3'e geçerken hangi kod kırılıyor?
• Swift 6.3'te actor isolation neden daha sıkı?
• Swift 6.4 ne zaman çıkacak?
• nonisolated ve @concurrent ne zaman kullanılır?
• 6.3'e geçmeden önce hangi build ayarlarını kontrol etmeliyim?
• Mevcut nonisolated(unsafe) kullanımlarımı 6.3'e geçmeden temizlemeli miyim?
• Sonuç
• Kaynaklar

Bugünün gerçeği: 6.3.3 yayında, 6.4 yolda

Swift 6.3, 24 Mart 2026'da resmi olarak yayınlandı ve Holly Borla ile Joe Heck imzasını taşıyordu. Duyuru yazısında öne çıkan başlıklar concurrency değil; daha esnek C interop, çapraz-platform build tooling iyileştirmeleri, gömülü (embedded) ortamlar için geliştirmeler ve resmi bir Android SDK'sı vardı. Yani resmi 6.3 duyurusunda concurrency başlığı bile yok; buna rağmen belgelenmiş vakadaki uyarı gerçek — nedenini aşağıda, region isolation analizinin muhafazakâr kuralında göreceksin.

Sürüm zincirini takip edersen bugün (Eylül 2026 başı) karşına çıkan tablo şöyle: 6.3 ana sürümünün ardından 6.3.1 ve 6.3.2 patch'leri geldi, 30 Haziran 2026'da da 6.3.3 yayınlandı — swift.org'un kurulum sayfasındaki güncel kararlı sürüm etiketi hâlâ bu. Bu arada Swift 6.4 hazırlığı da sürüyor: Xcode 27, Ağustos 2026 sonunda hâlâ beta aşamasındaydı (beta 6, 24 Ağustos 2026), yani 6.4 resmen yayınlanmış bir sürüm değil. swift.org'un 20 Ağustos 2026 tarihli "Embedded Swift Improvements Coming in Swift 6.4" yazısı da başlığında bile "coming" (geliyor) diyor — bu makalenin yazıldığı tarihte 6.4 hâlâ geliştirme snapshot'larıyla denenen bir sürüm.

Point-Free ekibinin Xcode 27 beta günlerine ait yazısı buna canlı bir örnek: ekip, Swift 6.4'teki bir isolation-checking regresyonu yüzünden zaten @MainActor olması gereken bir şeyi açıkça @MainActor işaretlemek zorunda kalmış ve ilgili PR'ı hızlıca birleştirip yeni bir sürüm yayınlamış.

6.2 → 6.3 dil değişiklikleri özeti

Swift 6.3'ün actor isolation'daki sıkılaşmasını anlamak için önce 6.2'de ne değiştiğini bilmen gerekiyor, çünkü uyarıyı tetikleyen konfigürasyonun yarısı — modülün default-isolation ayarı — 6.2'de SE-0466 ile geldi.

SE-0466 — Modül genelinde varsayılan actor isolation. Bu öneri, Swift 6.2'de "Implemented" statüsüne ulaştı ve derleyiciye modül içinde @MainActor çıkarımını varsayılan yapabilme ayarı ekledi. Amaç, tek-threadli kodun yanlış-pozitif veri yarışı hatalarını azaltmasıydı — önerinin kendi ifadesiyle: "Tek-threadli kodu modellemenin en kolay ve en iyi yolu global bir actor'dür. Global bir actor üzerindeki her şey sıralı çalışır."

SE-0461 — `nonisolated(nonsending)` varsayılanı. Yine 6.2'de "Implemented" olan bu öneri, nonisolated async fonksiyonların davranışını değiştirdi: artık bu tür fonksiyonlar varsayılan olarak çağıranın actor'ünde çalışıyor, ayrı bir executor'a atlamıyor. NonisolatedNonsendingByDefault upcoming-feature flag'i bu davranışı açıyor.

Bu iki değişiklik birlikte düşünüldüğünde 6.2'nin felsefesi netleşiyor: derleyici artık "varsayılan olarak sıralı, gerekirse paralel" mantığıyla çalışıyor. Swift 6.3 ise yeni bir concurrency varsayılanı duyurmadı; buna karşın 6.2'de sessizce derlenen bazı kalıplar 6.3'te yeni isolation uyarıları üretiyor.

Belgelenmiş vaka: `@Sendable` × `@escaping` isolation uyarısı

Swift Forums'ta Itai Ferber'ın açtığı bir konu, bu sıkılaşmanın en somut belgelenmiş örneği. Ferber'in tarif ettiği koşul çok net, kendi ifadesiyle: "Bu yalnızca nonisolated varsayılan isolation'a ve concurrency checking'i Complete'e ayarlanmış bir projede Swift 6.3 ile tekrarlanıyor; önceki Swift sürümleri, varsayılan MainActor isolation'ı veya minimal/hedefli concurrency checking bu uyarıyı üretmiyor."

Bu tanım kendi başına önemli bir pratik ipucu veriyor: eğer projen -default-isolation MainActor bayrağını kullanıyorsa (yani modül genelinde SE-0466'nın MainActor-varsayılanını açtıysan) bu spesifik uyarıyı görmeyeceksin. Uyarının çıktığı konfigürasyon şu: modülün varsayılan isolation'ı hâlâ nonisolated ve hedef SWIFT_STRICT_CONCURRENCY=complete ile derleniyor.

1// Ferber'in forum konusundaki reproducer: 6.2 sessiz, 6.3 uyarı veriyor
2class External {
3    // Sistemden gelen, Obj-C kökenli imza (gerçekte Timer.scheduledTimer)
4    static func ƒ1(_ work: @escaping @Sendable () -> Void) {
5        work()
6    }
7}
8 
9@MainActor
10final class Internal {
11    func ƒ2(_ completion: @escaping () -> Void) {
12        completion()
13    }
14 
15    func ƒ3() {
16        Task { @MainActor in
17            var complete = false
18            External.ƒ1 {
19                MainActor.assumeIsolated {
20                    self.ƒ2 {
21                        MainActor.assumeIsolated {
22                            // ⚠️ Sending 'complete' risks causing data races
23                            complete = true
24                        }
25                    }
26                }
27            }
28 
29            print(complete)
30        }
31    }
32}

Ferber'in forum konusundaki gerçek derleyici çıktısı şu şekilde: "complete gönderiliyor veri yarışına yol açabilir; bu Swift 6 dil modunda bir hatadır ... Task-isolated complete, main actor-izole bir closure tarafından yakalanıyor." Dikkat et: uyarı closure'ın kendisine değil, Task { @MainActor in } gövdesinde tanımlanan var complete değişkeninin yakalanmasına çıkıyor.

Bu uyarıyı gidermenin forum konusunda belgelenen iki yolu var: External.ƒ1()'den @Sendable'ı kaldırmak ya da Internal.ƒ2()'den @escaping'i kaldırmak. Ferber'in kendi cümlesiyle: "External.ƒ1()'den @Sendable'ı ya da Internal.ƒ2()'den @escaping'i kaldırmak uyarıyı çözüyor." Nedeni de konuda açıklanıyor: complete nonisolated bir bağlamdan geçtiği için MainActor'e örtük olarak gönderilmesi gerekiyor; sending semantiği ise değerin kaynak bağlamdan artık kullanılamayacağının statik doğrulanmasını istiyor ve bu nonisolated bağlamlarda yapılamıyor. Ferber tanıyı kabul ediyor: "böyle bir mutable var yakalaması için uyarı vermek mantıklı görünüyor."

Pratik çıkarım: -default-isolation bayrağını kontrol et — ama bunu tanı adımı olarak yap, çözüm olarak değil. Ayarı MainActor-varsayılanına çevirdiğinde uyarı kaybolur; bu, kodun yarışsız olduğunu kanıtlamaz. jamieQ'nun ifadesiyle "bu, region isolation analizi uygulamasının muhafazakâr kurallarının bir sınırlaması" — kod gerçekten güvenliyse bilinçli bir kaçış kapısı (nonisolated(unsafe)) makul bir yol. Alternatifi de aynı konuda öneriliyor: değeri, derleyicinin closure yakalaması için ürettiği örtük kutu yerine eşleşen isolation'a sahip kendi referans tipine koymak — @MainActor final class Workaround<T> gibi bir sarmalayıcı.

Kaçış kapıları: `nonisolated(unsafe)` ve `@preconcurrency`

nonisolated(unsafe), Swift 6 geçişlerinde en sık başvurulan kaçış kapılarından biri — ama bunu her yere serpiştirmek, geçişi hızlandırmak yerine gerçek veri yarışlarını gizlemenin bir yolu olabilir. Swift Forums'ta bir geliştiricinin paylaştığı gerçek geçiş deneyimi bu ayrımı net gösteriyor: "Birkaç legacy/spagetti kod sorunu çıktı ama nonisolated(unsafe) ile çözülebildi." Aynı yazıda üçüncü parti kütüphanelerle ilgili şu pratik not var: "Üçüncü parti kütüphanelerle uğraşmak oldukça kolaydı — sadece import'a veya protokole @preconcurrency eklemek ve devam etmek yeterliydi." Bu ikisi 6.3'e özgü değil, genel Swift 6 geçiş pratiğinin parçası, ama 6.3'e geçerken hâlâ karşına çıkacak ilk savunma hattı.

1import Foundation
2 
3// Legacy bir singleton'ı hızlıca susturmak (dikkatli kullan — gerçek veri yarışını gizleyebilir)
4final class LegacyCache {
5    nonisolated(unsafe) static var shared = LegacyCache()
6    private var storage: [String: Data] = [:]
7}
8 
9// Henüz Sendable-uyumlu olmayan, temsili bir üçüncü parti protokol
10protocol RequestDelegate {
11    func didFinish(_ payload: Data)
12}
13 
14@MainActor
15final class APIClient: @preconcurrency RequestDelegate {
16    // @preconcurrency, uyumun isolation kontrolünü çalışma zamanına erteler
17    func didFinish(_ payload: Data) {
18        print(payload.count)
19    }
20}

Protocol conformance'ların isolation'ı ayrı bir katman: SE-0470 "Global-actor isolated conformances" önerisi — proposal metnindeki statüsüyle "Implemented (Swift 6.2)" — bir tipin bir protokole global-actor izole şekilde uyum sağlamasını (@MainActor bir sınıfın nonisolated bir protokole uyması gibi durumları) kesin kurallara bağlıyor ve çıkarımı InferIsolatedConformances upcoming-feature bayrağıyla açıyor. Pratik etkisi şu: @MainActor işaretli bir tipin, isolation gerektirmeyen bir protokole uyduğu yerlerde açık işaretleme istenebiliyor.

Aynı vakanın kökü: region isolation analizi

Uyarının kökü, closure'ların hangi actor'de "resume" olduğundan çok, derleyicinin yakalanan değişkeni nasıl sınıflandırdığıyla ilgili: Task-izole complete, @MainActor-izole bir closure tarafından yakalandığı anda gönderilmiş sayılıyor.

Bunu, aynı konuda Swift ekibinden John McCall şöyle tarif ediyor: "Sorun basitçe şu: Swift, farklı isolation'a sahip bir closure'daki yakalamayı bir send gibi ele alıyor; oysa aslında yakalanan değişkenin kullanıldığı fonksiyonların isolation'ı üzerinden akıl yürütmemiz gerekirdi." Ayrım önemli: bu yalnızca dolaylı yakalamalarda — bir değişkenin sırf daha iç bir closure'da kullanıldığı için dıştaki closure'a da yakalandığı durumlarda — ortaya çıkıyor. Point-Free'nin Xcode 27/Swift 6.4 beta sürecine dair notu, NonisolatedNonsendingByDefault ayarını benimseyen kütüphanesinde 6.4'ün isolation denetimini sıkılaştırmaya devam ettiğini gösteriyor: "Swift 6.4, bu ayarla ilgili async koddaki daha fazla sorunu yakalamaya başlamış görünüyor" (buradaki "bu ayar" = NonisolatedNonsendingByDefault) — yani closure/async isolation kontrolü 6.3'ten 6.4'e doğru sıkılaşmaya devam ediyor, tek seferlik bir sıçrama değil, kademeli bir eğilim.

1import Foundation
2 
3// Karşıt örnek: burada isolation zinciri KIRILMIYOR — yukarıdaki
4// dolaylı-yakalama deseninin nasıl görünmediğini gösteriyor
5actor DownloadManager {
6    func fetch(completion: @escaping @Sendable (Result<Data, Error>) -> Void) {
7        Task {
8            let data = await performFetch()
9            // Task, actor'ün isolation'ını miras alıyor; completion @Sendable
10            // olduğu için sınırdan gönderilecek mutable bir yakalama yok
11            completion(.success(data))
12        }
13    }
14 
15    private func performFetch() async -> Data { Data() }
16}

Pratikte bu tür uyarılarla karşılaştığında ilk soracağın soru şu olmalı: "Bu closure hangi actor'de yaşamalı, ve isolation'ı açıkça mı yoksa çıkarım yoluyla mı belirleniyor?"

Uyarıları hataya çevirmeden aşamalı geçiş

6.3'e geçerken en yaygın hata, tüm hedefi tek seferde Swift 6 dil moduna çekmek. swift.org'un geçiş rehberi kuralı açıkça yazıyor: "Swift 6 dil modunu benimseyen hedeflerde complete checking koşulsuz olarak açıktır ve herhangi bir ayar değişikliği gerektirmez." Yani böyle bir ara yol yok; Swift Forums'taki geçiş anlatısında geçen "Önce Xcode'da dil sürümünü 6'ya ve concurrency checking'i minimal'e çevirdim" cümlesi de bu kuralla çelişiyor. Kademeli yol tersidir: hedefi Swift 5 dil modunda tutup Xcode'daki "Strict Concurrency Checking" ayarını minimal → targeted → complete diye yükselt, uyarıları temizledikten sonra dil modunu 6'ya çevir.

1// swift-tools-version: 6.0
2import PackageDescription
3 
4let package = Package(
5    name: "MyPackage",
6    targets: [
7        // Adım 1: v5 dil modu + complete checking (yalnız uyarı)
8        .target(
9            name: "LegacyModule",
10            swiftSettings: [
11                .swiftLanguageMode(.v5),
12                .enableUpcomingFeature("StrictConcurrency")
13            ]
14        ),
15        // Adım 2: swiftSettings silinir, hedef varsayılan v6 diline döner
16        .target(name: "MigratedModule")
17    ]
18)

İkinci adım, dikkatsizce serpiştirilmiş @MainActor işaretlemelerini geri almak. Aynı forum yazısındaki dürüst itiraf şu: "Sonradan geriye baktığımda, dikkatsizce eklediğim bazı mainactor işaretlemelerini kaldırabildiğimi fark ettim." Bu, geçiş sırasında "hatayı sustur" refleksiyle her yere @MainActor eklemenin, sonradan temizlenmesi gereken bir teknik borç yarattığını gösteriyor — ilk geçişte agresif izolasyon eklemek yerine, derleyicinin gösterdiği gerçek veri yarışı noktasını anlayıp orada düzeltme yapmak daha sürdürülebilir.

Üçüncü adım, bir derleyici regresyonu ya da muhafazakâr bir tanıyla karşılaştığında ekip issue açıp geçici bir workaround uygulamak — dil ekibinin düzeltmesini beklemeden. Point-Free'nin yaklaşımı bunu net özetliyor: "Bu sorunlarla ilgili issue'lar açtık, ama bu kullanıcılarımıza yardımcı olmuyor. Bu yüzden bu arada workaround'lar uyguladık." Yani derleyici regresyonuna takılırsan, projenin ilerlemesini bir dil-ekibi düzeltmesine bağlamak yerine, işaretleme ekleyip devam et ve issue'yu ayrıca takip et.

SPM paketlerinde sürüm çakışması yönetimi

Sürüm yükseltmesi yalnızca senin kodunu değil, bağımlı olduğun SPM paketlerini de etkiler — ve bu paketlerin bakımcıları da aynı regresyonlarla senden önce karşılaşmış olabilir. Point-Free'nin ComposableArchitecture ve StructuredQueries kütüphanelerindeki deneyimi, bu döngünün nasıl işlediğine iyi bir örnek. StructuredQueries için: "Swift 6.4, @Table makrosu kodunun derlenmesini engelleyen küçük bir tip denetimi regresyonu getirmiş görünüyor. Düzeltme basitti ... ve 2 gün içinde bir sürüm yayınladık." ComposableArchitecture için de benzer bir hızlı-düzeltme-ve-yayınlama döngüsü yaşanmış (yukarıda geçen @MainActor işaretlemesi örneği).

Bu, 6.3'e (veya ileride 6.4'e) geçerken bağımlılık yönetiminde izlenecek somut bir sırayı gösteriyor:

• Önce paket sürümlerini kontrol et: kullandığın kritik paketlerin (ComposableArchitecture, StructuredQueries gibi) CHANGELOG'unda "Swift 6.3" veya "isolation" geçen bir patch notu var mı bak.
• Paketi güncellemeden hedefi yükseltme: derleyici sürümünü değiştirmeden önce swift package update ile bağımlılıkları en son patch'e çek — bakımcılar genelde senden önce regresyona çarpmış olur.
• Kilitli sürüm varsa issue takip et: eğer Package.resolved bir sürümü kilitlemişse ve o sürüm 6.3 öncesine aitse, paketin GitHub issue'larında "6.3" veya "isolation" araması yap.
• Kendi fork'unda geçici workaround: kritik bir paket henüz düzeltme yayınlamadıysa — Point-Free'nin bakımcı tarafında yaptığına benzer bir refleksle — issue'yu aç ve kendi entegrasyon katmanında geçici bir nonisolated(unsafe) veya açık @MainActor ekleyip paketin resmi düzeltmesini bekle — paketi fork'lamak yerine.

Bu iki kütüphane örneği aynı zamanda şunu doğruluyor: sürüm geçişlerinde yaşanan isolation regresyonları yalnız senin kod tabanına özgü değil, üretimde kullanılan popüler kütüphaneler de aynı sürtünmeyi yaşıyor — yalnız olmadığını bilmek bile geçiş sürecinde moral olarak işe yarıyor.

Swift 6.4'te ne bekleniyor

Swift 6.4 için resmi bir GA (genel kullanıma sunum) tarihi henüz açıklanmadı — Eylül 2026 başı itibarıyla Xcode 27 hâlâ beta aşamasında. Ama swift.org'un Doug Gregor imzalı 20 Ağustos 2026 tarihli blog yazısı, Embedded Swift tarafında 6.4 ile gelecek somut iyileştirmeleri açık şekilde belgeliyor: "Embedded Swift daha önce yalnızca AnyObject kısıtlamasına sahip existential (any) tipleri destekliyordu ... Artık Any'nin kendisi dahil tüm any tipleri Embedded Swift'te kullanılabilir." Aynı yazıda untyped throws desteği de genişliyor: "Untyped throws, any Error tipinde bir değer fırlatmakla eşdeğerdir. any tiplerinin genelleştirilmesiyle Embedded Swift artık untyped throws'u tam olarak destekliyor." Metatype'lar ise yazıda ayrı bir başlık: "Swift 6.4, Embedded Swift'te metatype'lar için eksiksiz destek getiriyor."

Bu değişiklikler doğrudan actor isolation'ı hedeflemiyor, ama gömülü sistemlerde (mikrodenetleyiciler, WebAssembly hedefleri) Swift kullanan ekipler için önemli — ve Point-Free'nin deneyimi gösteriyor ki 6.4'ün concurrency checking tarafı da 6.3'ün sıkılaşma eğilimini sürdürüyor, bazen mevcut kodda yeni regresyonlar açığa çıkarıyor. Pratik tavsiye: 6.3'e geçişini tamamlamadan 6.4 beta'sına atlama — her iki sürümün isolation davranışı arasındaki farkı ayrı ayrı izlemek, hangi uyarının hangi sürümden geldiğini anlamanı kolaylaştırır.

Xcode 27 beta'larını takip eden bir ekipsen, swift.org/blog sayfasındaki aylık dijestleri (4 Eylül 2026 tarihli "What's new in Swift: August 2026 Edition" gibi) izlemek, 6.4'ün kararlı sürüme yaklaştığı anı kaçırmamanın en güvenilir yolu — resmi duyuru genelde Xcode'un kendi GA'sıyla eş zamanlı geliyor.

SSS

Swift 6.2'den 6.3'e geçerken hangi kod kırılıyor?

En yaygın kırılma noktası, nonisolated modül-varsayılanı ile Complete concurrency checking kombinasyonunda @Sendable @escaping closure'lar kullanan kod. Swift Forums'ta belgelenen bir vakada, bu kombinasyon 6.2'de sessizce derlenirken 6.3'te "veri yarışına yol açabilir" uyarısı vermeye başlıyor. Genel kural şu: bir deklarasyonun isolation durumu (isolated/nonisolated) API sözleşmesinin bir parçası olduğundan, sürüm yükseltmesi bu sözleşmenin nasıl denetlendiğini değiştirebiliyor.

Swift 6.3'te actor isolation neden daha sıkı?

Resmi 6.3 duyurusu yeni bir concurrency özelliği ilan etmiyor; buna karşın 6.2'de sessizce derlenen bazı kalıplar 6.3'te uyarı üretiyor. Belgelenmiş vakada kaynak yeni bir kural değil, region isolation analizinin muhafazakâr davranışı: farklı isolation'a sahip bir closure'da yakalanan mutable değişken "gönderilmiş" sayılıyor.

Swift 6.4 ne zaman çıkacak?

Kesin bir GA tarihi resmi olarak açıklanmadı. Bilinen: Xcode 27 (Swift 6.4'ü içeriyor) Haziran 2026'dan beri beta aşamasında ve 24 Ağustos 2026 itibarıyla beta 6'daydı. swift.org'un 20 Ağustos 2026 tarihli Embedded Swift yazısı da 6.4'ü hâlâ "coming" (geliyor) diye tanımlıyor — Eylül 2026 başı itibarıyla 6.4 resmi olarak yayınlanmış değil.

nonisolated ve @concurrent ne zaman kullanılır?

nonisolated(nonsending), çağıranın işinin mantıksal bir parçası olan ve ayrı bir thread'e geçmesi gerekmeyen yardımcı fonksiyonlar için uygun — bu fonksiyonlar çağıranın actor'ünde kalır. @concurrent ise gerçekten paralel çalışması gereken, çağıranın actor'ünü bloklamaması istenen pahalı işler için, eski "her zaman ayrı executor'da çalış" davranışını açıkça talep etmek amacıyla kullanılır. NonisolatedNonsendingByDefault bayrağı açıldığında düz nonisolated async fonksiyonlar varsayılan olarak çağıranın actor'ünde kalır; eski davranışı korumak istediğin fonksiyonları @concurrent ile açıkça işaretlemen gerekir.

6.3'e geçmeden önce hangi build ayarlarını kontrol etmeliyim?

Hedefinin -default-isolation bayrağını (MainActor mı, nonisolated mı) ve SWIFT_STRICT_CONCURRENCY seviyesini (minimal/targeted/complete) kontrol et. Bu yazıdaki forum bulgusuna göre, aynı kod bu iki ayarın kombinasyonuna bağlı olarak 6.3'te farklı sonuç veriyor — MainActor-varsayılanı açık projelerde belgelenen uyarı çıkmıyor.

Mevcut nonisolated(unsafe) kullanımlarımı 6.3'e geçmeden temizlemeli miyim?

Zorunlu değil ama önerilir. nonisolated(unsafe) geçici bir kaçış kapısı olarak kalmalı; 6.3'e geçiş, bu işaretlemelerin hâlâ gerekli olup olmadığını (yoksa yalnızca eski bir "sustur ve geç" refleksinin kalıntısı mı olduğunu) gözden geçirmek için iyi bir fırsat.

Sonuç

Swift 6.3'e geçiş, yeni bir dil özelliği öğrenmekten çok, 6.2'nin getirdiği actor isolation varsayılanlarının (SE-0466, SE-0461) derleyicide nasıl denetlendiğini anlamakla ilgili. Belgelenmiş vaka dersi tek başına veriyor: Sendable+escaping bir imzanın ardında dolaylı yakalanan mutable değişken, region isolation analizinin muhafazakâr kuralına takılıyor. Protocol conformance isolation'ı (SE-0470) da aynı köke bağlanıyor: isolation artık API sözleşmesinin denetlenen bir parçası. Eğer bu geçişten önce Swift'in strict concurrency temellerini tazelemek istersen Swift 6 Strict Concurrency Derin Rehberi iyi bir başlangıç noktası; adım adım bir migration planı arıyorsan Swift 6 Strict Concurrency Migration Playbook bu yazının tamamlayıcısı.

Actor'lerin temel çalışma mantığına daha derin bakmak istersen Swift Concurrency ve Actor'lar makalesine, yapılandırılmış eşzamanlılığın (structured concurrency) Task ve TaskGroup tarafına Swift Structured Concurrency yazısına bakabilirsin. Dağıtık sistemlerde actor kullanan projeler için Swift Distributed Actors bu yazının kapsamadığı ağ-ötesi isolation senaryolarını ele alıyor. WWDC26'da Swift 6.2 ile gelen genel concurrency yeniliklerine dair arka planı Swift 6.2 Concurrency Yenilikleri yazısından tazeleyebilirsin.

Son not: bu makaledeki tüm örnekler 6.3.3 (bugünkü kararlı sürüm) baz alınarak yazıldı. Xcode 27 beta'sıyla Swift 6.4'ü denemeye başladıysan, isolation davranışının 6.3'ten farklı olabileceğini unutma — iki sürümün regresyonlarını aynı geçiş sürecinde karıştırmamak, hangi uyarının nereden geldiğini anlamanı kolaylaştırır.

Kaynaklar

• Swift 6.3 Released — resmi 6.3 duyurusu, 24 Mart 2026, dil değişikliklerinin özeti
• Announcing Swift 6.3.3 — 30 Haziran 2026 patch duyurusu, güncel kararlı sürüm
• Embedded Swift Improvements Coming in Swift 6.4 — 20 Ağustos 2026, Doug Gregor, 6.4'ün henüz yayınlanmadığının resmi kanıtı
• SE-0466: Control Default Actor Isolation — modül-genelinde varsayılan isolation önerisi, 6.2'de Implemented
• SE-0461: Run nonisolated async functions on the caller's actor — nonisolated(nonsending) önerisi, 6.2'de Implemented
• New Swift 6.3 isolation warnings with Sendable x escaping escape hatch — Itai Ferber, Swift Forums, 25 Şubat 2026, bu yazının temel kaynağı
• My experience (attempting) a migration to swift 6 — Swift Forums, 3 Nisan 2025, Swift 6.0 dönemi kademeli geçiş anlatısı
• Xcode 27 Support in the Point-Free Ecosystem — Point-Free, ComposableArchitecture/StructuredQueries'teki gerçek regresyon-düzeltme örnekleri
• Enable data-race safety checking — swift.org geçiş rehberi, dil modu ve checking seviyesi kuralları
• What's new in Swift: August 2026 Edition — swift.org, 4 Eylül 2026, aylık dijest