آزمایش `splat` در Rust برای اتصال بهتر به C++؛ پیش از آن‌که سربارگذاری به RFC برسد

Rust در حال آزمایش تغییری کوچک اما مهم در مرز زبان‌هاست: آزمایشی nightly به نام splat که می‌تواند فراخوانی توابع سربارگذاری‌شدهٔ C++ از Rust را ساده‌تر کند.

تیم زبان Rust این آزمایش را در ۱۹ اوت ۲۰۲۶ معرفی کرد. این کار با همکاری ابتکار Rust-C++ Interop بنیاد Rust انجام می‌شود و در گام نخست برای رابط‌های تابع خارجی (FFI) طراحی شده است، نه برای بازطراحی APIهای معمول Rust.

Rust پایدار امروز می‌تواند نوعی سربارگذاری را با traitها و tupleها مدل کند. این روش type-safe است، اما فراخوانی‌ها را نامأنوس می‌کند. برای نمونه، یک binding تولیدشده ممکن است به hypot((2.0, 3.0, 6.0)) نیاز داشته باشد، نه شکل رایج C++ یعنی hypot(2.0, 3.0, 6.0). راه‌حل دیگر، نام‌گذاری جداگانهٔ هر overload است؛ مثلاً توابعی مانند func1 و func2.

این راه‌حل‌ها مشکل نگه‌داری ایجاد می‌کنند. وقتی یک کتابخانهٔ C++ overload جدیدی اضافه یا یکی را حذف می‌کند، معمولاً فراخوان‌های بومی آن کتابخانه همچنان از همان مجموعهٔ overload استفاده می‌کنند. اما bindingهای Rust ممکن است به نام‌های تازه، boilerplate بیشتر یا سازگارسازی دستی نیاز پیدا کنند. به همین دلیل، هدف پذیرفته‌شدهٔ پروژهٔ Rust مسئله را صرفاً زیبایی نحوی نمی‌داند: پشتیبانی از کاربران Rust نباید بار نگه‌داری بیشتری بر صاحبان کتابخانه‌های C++ تحمیل کند.

آزمایش فعلی از ویژگی داخلی #[rustc_splat] استفاده می‌کند. یک تابع می‌تواند tupleی از آرگومان‌ها را دریافت کند، اما فراخواننده آرگومان‌ها را جداگانه بنویسد. در مثال پروژه، پیاده‌سازی‌های نسخهٔ دوآرگومانی و سه‌آرگومانی std::hypot در C++ از طریق traitهای موجود انتخاب می‌شوند، در حالی که محل فراخوانی به شکل hypot(3.0, 4.0) و hypot(2.0, 3.0, 6.0) دیده می‌شود.

این طراحی عمداً موقتی است. پروژه می‌خواهد بسنجد سازوکار type و trait فعلی Rust تا چه حد می‌تواند مجموعه‌های overload خارجی را پشتیبانی کند، چه diagnosticهایی لازم است و قواعد coherence در کجا با الگوهایی که C++ مجاز می‌داند مقابله می‌کنند. C++ می‌تواند نامزدهای هم‌پوشان داشته باشد و با فرایندی چندمرحله‌ای بهترین تابع قابل‌اجرا را انتخاب کند؛ در حالی که سیستم trait در Rust معمولاً پیاده‌سازی‌های هم‌پوشان را رد می‌کند و بین آن‌ها انتخاب نمی‌کند.

هدف پروژه مرز راهبردی را هم روشن می‌کند. Rust لازم نیست lookup وابسته به آرگومان یا همهٔ قواعد resolution زبان C++ را بازسازی کند. طراحی آینده شاید برای رفع ابهام به تبدیل‌ها یا markerهای صریح نیاز داشته باشد. هدف، ساختن رابطی قابل‌پیش‌بینی برای APIهای خارجی است، نه واردکردن کامل معناشناسی C++ به Rust.

برای توسعه‌دهندگان compiler و ابزارهای interop، آزمایش روی buildهای Rust nightly از ۳۱ ژوئیهٔ ۲۰۲۶ ممکن است. نوشتهٔ تیم همچنین از پشتیبانی تازه برای rustdoc و function pointerها و یک آزمایش کتابخانهٔ استاندارد برای توابع چندآرگومانی smallest و greatest خبر می‌دهد.

نکتهٔ مهم این است که splat یک آزمایش ناقص و فقط nightly، بدون RFC است. این ویژگی ممکن است به‌طور اساسی تغییر کند یا حذف شود؛ بنابراین مسیر مهاجرت پایدار محسوب نمی‌شود. بنیاد Rust آن را یک تمرین برای ترسیم محدوده می‌داند: مشخص‌کردن جایی که سیستم type انعطاف‌پذیر است، جایی که مقاومت می‌کند و این‌که یک RFC آینده چه تعهداتی باید بدهد یا ندهد.

برای سازندگان ICP و دیگر پروژه‌های Rust که به کتابخانه‌های C++ وابسته‌اند، اقدام فوری محدود است: bindingهای واقعی و نماینده را روی nightly آزمایش کنند، خطاهای overload resolution را ثبت کنند و نمونه‌های مشخص interop را گزارش دهند. پیام بزرگ‌تر این است که پیشرفت بعدی Rust در FFI شاید با حفظ مدل نگه‌داری کتابخانهٔ خارجی سنجیده شود، نه فقط با کوتاه‌ترشدن کد binding تولیدشده.