Go 1.27 generic metotları getiriyor ama arayüzlerde yasaklıyor, tasarım tartışması başlatıyor

Generic metotlar Go 1.27 ile geliyor

Go 1.27, 19 Ağustos 2026'da yayınlandı ve bu sürümle birlikte dil, somut tipler üzerinde — özellikle struct'lar — kendi type parametrelerini taşıyan metotlar tanımlama desteği kazandı. Bu değişiklik, yaşanan tarihe bakılırsa dikkat çekici: yaklaşık on yıl boyunca resmi Go SSS, generic metotların gerçekleşmesinin beklenmediğini söylemişti. Sürümü inceleyen bir dev.to yazısına göre, süreç bir kez başladığında hızlı ilerledi. Go'nun ortak tasarımcısı Robert Griesemer Ocak 2026'da #77273 numaralı öneriyi sundu, öneri Mayıs'ta kabul edildi ve özellik Ağustos'ta yayınlandı.

Sürüm ayrıca birçok kullanıcıyı rahatsız eden bir sınırlama da getiriyor: arayüzler hiçbir koşulda generic metotlar tanımlayamıyor.

Arayüzler neden dışlandı

Öneride açıklanan ve dev.to yazısında özetlenen gerekçe, temelde bir runtime kısıtı. Derleyici, bir program çalışırken generic bir metodun sınırsız olası instantiation'ından hangilerine ihtiyaç duyulacağını önceden belirleyemiyor. Yazıda alıntılanan Griesemer, somut metotları "arayüzlerle hiçbir ilgisi olmayan nedenlerle, kendi değerimiz için istediğimiz bir dil özelliği" olarak nitelemiş — yani bu sınırlama bir özür değil, bir duruş.

Aynı yazıda alıntılanan yazılım mühendisi Corentin Giauque Saubert, pratik sonuçlarını açık bir dille anlattı: arayüzlerdeki generic metotlar type erasure'ı zayıflatır, dinamik dispatch'i karmaşıklaştırır ve reflection ile çelişirdi. Bu maliyetin bir işareti Go 1.27'nin kendisinde de görülüyor — generic metotlar reflect paketine görünmez, çünkü gerekli bilgi runtime'da mevcut değil.

Ortogonallik itirazı

Kısıtlamanın eleştirmenleri tanıdık bir ilkeye dayanıyor: Go'da metotlar ve arayüzler geleneksel olarak tek bir tasarımın birbirinin aynası olan iki yarısı olarak ele alındı; bir tipin bir metot üzerinden yapabildiği her şey bir arayüz üzerinden de ifade edilebiliyordu. Hiçbir arayüzün referans veremediği bir generic metot, onlara göre dilin geri kalanından tecrit edilmiş bir özellik gibi görünüyor — eksik ya da tip sistemindeki açıkları gizlemek için bilinçli olarak budanmış.

dev.to yazarı bu eleştirinin gerçek bir şeyi tanımladığını kabul ediyor, ancak böyle bir simetrinin bir amaç değil araç olduğunu savunuyor. Yazıya göre asıl hedef, sıradan bir geliştiricinin kafasında tutabileceği bir tip sistemi. Arayüzlerin içinde generic metotlara izin vermek bir demoda kusursuz görünebilirdi ama gerçek dağıtımlarda reflection tabanlı araçları sessizce bozacaktı. Bu okumaya göre ret bir başarısızlık değil disiplin: dil, ekosisteme karmaşıklık sızdıran cazip özellik yerine öngörülebilir şekilde derlenen daha az göz alıcı özelliği seçti.

Neden önemli

Sürüm, Go'nun on yıllık "hayır" döneminden sonra nasıl yönetildiğinin bir fotoğrafı. Geliştiriciler artık somut tiplere bağlı metotlarda type parametreleri kullanabiliyor ve bu gerçek bir ifade gücü kazandırıyor; ancak arayüzlere dayalı herhangi bir desen — deyimsel Go'nun büyük bir bölümü — bu metotları tanımlayamıyor ve reflect'e dayanan kod onları hiç göremiyor. Özelliği erken benimseyen ekipler, generic metotların arayüz odaklı soyutlamalarla veya reflection tabanlı araçlarla kesiştiği her yerde sürtünme beklemeli. Daha geniş açıdan bakıldığında, bu olay her dilin er ya da geç karşılaştığı bir soruyu çerçeveliyor: yeni bir özelliğin içindeki sert bir sınır, zayıf bir tasarımın mı yoksa bilinçli bir koruma eyleminin mi işareti? Isınan topluluk tepkilerine bakılırsa, bu çizginin nereye çekilmesi gerektiği tartışması hiç de bitmiş değil.