C# 16 Unsafe Yeniden Doğuyor: Bellek Güvenliğinde Yeni Çağ

Açık konuşayım, ilk okuyunca ben de “yine mi unsafe tartışması?” dedim. Sonra GitHub’daki PR’a biraz gömülünce fikir değişti; bu sefer işin rengi farklı. C# ekibi unsafe anahtar kelimesini neredeyse baştan kuruyor, hem de Rust ve Swift’ten esinlenerek. Yani artık sadece “şu satırda pointer var, dikkat” demekle kalmıyoruz.

Yıllardır.NET tarafında çalışan biri olarak şunu rahatça söyleyebilirim: bu değişiklik, nullable reference types’ın 2019’da yarattığı etkiye baya yakın duruyor. Hatta belki bir tık üstü. Çünkü mesele sadece sözdizimi değil, işin içinde bir sözleşme modeli var.

Lafı fazla dolandırmadan dalalım.

Önce şu “unsafe” meselesini hatırlayalım

C# 1.0’dan beri unsafe vardı, yani 2002’den beri. O günlerde mantık çok basitti: pointer kullanacaksan “ben ne yaptığımı biliyorum” diye el kaldırıyordun. Compiler da sana bakıp “tamam, ben karışmıyorum” diyordu.

Ama yıllar geçince tablo dağıldı biraz. System.Runtime.CompilerServices.Unsafe geldi, Marshal geldi, MemoryMarshal geldi… Bunların hepsi riskli işler yapıyordu ama garip şekilde çoğu zaman unsafe istemiyordu. Yani yük tamamen alışkanlığa kaldı; “iyi geliştirici zaten dikkat eder” kafası çalışıyordu.

Bence işin aslı şu: o yaklaşım 2010’larda idare ediyordu. Şimdi işe LLM’ler kod üretiyor, junior bir arkadaş Copilot’tan MemoryMarshal.Cast çekiyor ve ortada hiçbir kırmızı bayrak yok. Tehlike oradaydı zaten. Ben Logosoft’ta bir bankacılık projesinde buna benzer bir şeyi yaşamıştım; code review sırasında Unsafe.As<T>‘yi fark etmek için ya tecrübeli göz gerekiyordu ya da düzgün ayarlı bir analyzer (ikisi de her ekipte bulunmuyor maalesef).

Peki yeni model neyi değiştiriyor?

Kısaca şöyle: unsafe, artık sadece bir sözdizimi etiketi gibi davranmayacak; daha çok bir sözleşme işareti olacak. Yani “burada pointer var” demekten ziyade, “bu kodu çağıran tarafın bazı şeyleri garanti etmesi lazım” diyecek.

Bence, Rust bilenlere tanıdık gelecek bu yapı. Rust’taki unsafe fn, fonksiyonun içinde tehlikeli şeyler döndüğünü değil, fonksiyonu çağırmadan önce çağıranın sağlaması gereken invariant’lar olduğunu söylüyor. C# tarafı da aynı tarafa kayıyor gibi duruyor.

Birkaç temel fark var:

• Yayılma (propagation): Bir unsafe metodu çağıran kod da ya kendi başına unsafe olacak ya da bir unsafe bloğunun içine girecek. Compiler bunu artık zorlayacak.
• Kapsam genişlemesi: Sadece pointer içeren parçalar değil, compiler’ın güvenliğini doğrulayamadığı bütün alanlar. Mesela Unsafe, Marshal, span üzerinde tıp dönüşümleri… bunlar da işin içine giriyor.
• Safety yorumları: Yeni bir // SAFETY:` tarzı geliyor. Bir `unsafe` bloğu açınca neden güvenli olduğunu yazmanız bekleniyor. Compiler bunu tek başına dayatmayacak ama analyzer’lar ve code review araçları bunu yakalayabilecek.

“unsafe artık bir sözdizimi türünü değil, bir sözleşme türünü işaretliyor — yetenekli bir geliştiricinin okuyup onaylaması gereken, compiler’ın doğrulayamadığı bir sözleşme.”

Peki pratikte nasıl görünecek?

Somut örnek iyi ölür diye düşündüm; aşağıya eski ve yeni yaklaşımı yan yana koydum:

// ESKİ MODEL (C# 1.0 — 15)
public Span<byte> GetBytes(int[] data)
{
// Marshal.UnsafeAddrOfPinnedArrayElement güvensiz
// ama unsafe işareti gerekmiyor — convention'a kalmış
return MemoryMarshal.AsBytes(data.AsSpan());
}
// YENİ MODEL (C# 16 önizleme)
public Span<byte> GetBytes(int[] data)
{
unsafe
{
// SAFETY: data dizisi method scope'unda canlı,
// pointer yaşam süresi span ile sınırlı,
// tip dönüşümü byte boyut hizalamasını korur.
return MemoryMarshal.AsBytes(data.AsSpan());
}
}

Şöyle söyleyeyim, Dikkat edin, fark küçük gibi duruyor ama etkisi başka. Eski kodda ortada uyarı falan yok; sanki sıradan güvenli API çağrısı yapıyormuşsunuz gibi görünüyor. Yeni modelde işe (belki yanilıyorum ama) hem açıkça bir `unsafe` bloğu var hem de neden güvenli olduğuna dair not düşülmüş durumda. Code review yapan kişi tek bakışta “buraya ekstra dikkat lazım” diyebiliyor. Python Agent Skills: Üç Yöntem, Tek Provider Se… yazımızda bu konuya da değinmiştik. Bu konuyla ilgili NL2SQL Gerçekten İşe Yarıyor mu? SQL MCP Server Notları yazımıza da göz atmanızı tavsiye ederim.

Bunu niye şimdi yapıyorlar? AI yüzünden mi?

Evet, bence büyük ölçüde öyle. Microsoft bloğunda hafifçe geçiliyor ama ben açık söyleyeyim: AI destekli kod üretimi manuel code review hızını çoktan solladı bile.

Daha geçen ay bir müşteride şuna benzer bir olay yaşadık: geliştirici Copilot’tan performans iyileştirmesi istemişti, Copilot da içinde >Unsafe.ReadUnaligned` olan bir çözüm önermişti (kod çalışıyor, testler yeşil, PR hazır). Eğer o gün ben PR'a bakmasaydım muhtemelen production'a inecekti; ARM tabanlı cihazda alignment sıkıntısı çıkarması da kuvvetle muhtemeldi. Visual Studio Plan Agent: Önce Düşün, Sonra Kodla yazımızda bu konuya da değinmiştik.

Sorun Copilot’un kötü olması değildi aslında. Sorun şu: tehlikeli kod ile sıradan kod arasında gözle görülür netlik yoktu. Yeni model olsaydı Copilot ya bunu `unsafe` bloğunda üretmek zorunda kalacaktı ya da derleyici suratına hata çarpacaktı — ikisi de fena değil hani.

Peki neden? Daha fazla bilgi için MCP Sunucuları İçin Yönetişim: .NET’e Yeni Toolkit Geldi yazımıza bakabilirsiniz. Cosmos Conf 2026: AI Çağında Veritabanı Nereye Gidiyor? yazımızda bu konuya da değinmiştik.