Rust 1.99, C ABI’si için değişken argümanlı fonksiyon tanımlamayı kararlı hâle getirdi; bu özellik normal Rust ABI’sinde genel amaçlı varargs sağlamaz.
Kararı şu ayrımla verin: Rust kodundan C uyumlu bir API sunmanız mı gerekiyor, yoksa yalnızca Rust içinde değişken sayıda değer mi işleyeceksiniz? İki ihtiyacın uygun arayüzü farklıdır.
1 Ekim 2026’da yayımlanan Rust 1.99.0, C ve C-unwind ABI’leriyle değişken argüman kabul eden fonksiyonları Rust’ta tanımlamayı kararlı hâle getirdi. Rust daha önce C tarafında tanımlanmış printf benzeri variadic fonksiyonları çağırabiliyordu; yenilik, uygun C ABI’li fonksiyon tanımının da Rust içinde yazılabilmesidir.
Fonksiyonun son parametresi... biçimindedir. Örneğin imza, unsafe extern "C" fn sum(mut args:...) -> i32 biçiminde yazılabilir. Gövdedeki VaList üzerinden argümanlar sırayla okunur. Önemli nokta, bu imzanın C ile uyumlu bir FFI sınırına ait olmasıdır; normal bir Rust fonksiyonuna sonradan genel amaçlı değişken parametreler eklemez.
Bu özelliği, dışarıya C uyumlu bir arayüz sunmanız ve o arayüzün değişken argümanlı olması gerektiğinde değerlendirin. Örneğin mevcut bir C API’si Rust’a taşınıyorsa ya da C tarafındaki çağıranların kullanacağı bir fonksiyon yazılıyorsa, C ABI’siyle uyum önemli olabilir.
Yalnızca Rust kodunun çağıracağı bir fonksiyona “istediğim kadar argüman göndereyim” davranışı kazandırmak için C variadic özelliğini seçmeyin. Aynı türden birden çok değeri işliyorsanız & veya bir iterator alan arayüz; çağrıda alan sayısı sabit kalıyorsa açık parametreler genellikle ihtiyaca daha uygun olur. C ABI’si, FFI gerekmiyorsa gereksiz bir dış sözleşme ve güvenlik yükü ekler.
Variadic argümanlarda çağıran tarafın gönderdiği sayı ve türlerle fonksiyonun okuduğu değerler uyuşmalıdır. Fonksiyon, kaç argüman beklediğini ve bunların türlerini kendi API sözleşmesinde belirtmeli; C tarafındaki çağrı da bu sözleşmeye uymalıdır. Türü yanlış okumak veya listede olmayan bir argümanı okumaya çalışmak tanımsız davranışa yol açabilir.
VaList’ten okunabilen türler VaArgSafe sınırına tabidir; bu kısıtlama, çağıranın yanlış tür göndermesini otomatik olarak denetlemez. Dolayısıyla C variadic desteği, tür güvenli genel amaçlı bir Rust varargs API’si değildir. Gerçek bir C FFI gereksinimi yoksa değişken veriyi Rust’ın açık türleriyle temsil eden bir imza seçin.
Kararı şu ayrımla verin: Rust kodundan C uyumlu bir API sunmanız mı gerekiyor, yoksa yalnızca Rust içinde değişken sayıda değer mi işleyeceksiniz? İki ihtiyacın uygun arayüzü farklıdır.
Rust 1.99’de ne değişti?
1 Ekim 2026’da yayımlanan Rust 1.99.0, C ve C-unwind ABI’leriyle değişken argüman kabul eden fonksiyonları Rust’ta tanımlamayı kararlı hâle getirdi. Rust daha önce C tarafında tanımlanmış printf benzeri variadic fonksiyonları çağırabiliyordu; yenilik, uygun C ABI’li fonksiyon tanımının da Rust içinde yazılabilmesidir.
Fonksiyonun son parametresi... biçimindedir. Örneğin imza, unsafe extern "C" fn sum(mut args:...) -> i32 biçiminde yazılabilir. Gövdedeki VaList üzerinden argümanlar sırayla okunur. Önemli nokta, bu imzanın C ile uyumlu bir FFI sınırına ait olmasıdır; normal bir Rust fonksiyonuna sonradan genel amaçlı değişken parametreler eklemez.
Hangi durumda kullanmak mantıklı?
Bu özelliği, dışarıya C uyumlu bir arayüz sunmanız ve o arayüzün değişken argümanlı olması gerektiğinde değerlendirin. Örneğin mevcut bir C API’si Rust’a taşınıyorsa ya da C tarafındaki çağıranların kullanacağı bir fonksiyon yazılıyorsa, C ABI’siyle uyum önemli olabilir.
Yalnızca Rust kodunun çağıracağı bir fonksiyona “istediğim kadar argüman göndereyim” davranışı kazandırmak için C variadic özelliğini seçmeyin. Aynı türden birden çok değeri işliyorsanız & veya bir iterator alan arayüz; çağrıda alan sayısı sabit kalıyorsa açık parametreler genellikle ihtiyaca daha uygun olur. C ABI’si, FFI gerekmiyorsa gereksiz bir dış sözleşme ve güvenlik yükü ekler.
Tür ve çağrı sözleşmesini nasıl korursunuz?
Variadic argümanlarda çağıran tarafın gönderdiği sayı ve türlerle fonksiyonun okuduğu değerler uyuşmalıdır. Fonksiyon, kaç argüman beklediğini ve bunların türlerini kendi API sözleşmesinde belirtmeli; C tarafındaki çağrı da bu sözleşmeye uymalıdır. Türü yanlış okumak veya listede olmayan bir argümanı okumaya çalışmak tanımsız davranışa yol açabilir.
VaList’ten okunabilen türler VaArgSafe sınırına tabidir; bu kısıtlama, çağıranın yanlış tür göndermesini otomatik olarak denetlemez. Dolayısıyla C variadic desteği, tür güvenli genel amaçlı bir Rust varargs API’si değildir. Gerçek bir C FFI gereksinimi yoksa değişken veriyi Rust’ın açık türleriyle temsil eden bir imza seçin.