EN
→ بازگشت به خبرخوان
شمارهٔ ۰۳۰۰Rust۲ دقیقه۳ منبع

آزمایش Splat در Rust، انسجام traitها را در مرکز آزمون قرار می‌دهد

آزمایش شبانه‌روزی جدید Rust با جدا کردن آرگومان‌های tuple‌شده، فراخوانی overloadها را طبیعی‌تر می‌کند؛ اما آزمون اصلی این است که آیا قواعد trait در مواجهه با overloadهای خارجی همچنان شفاف و منسجم می‌مانند یا نه.

اشتراک‌گذاری
راست (Rust)
آزمایش Splat در Rust، انسجام traitها را در مرکز آزمون قرار می‌دهد
تصویر: تولید هوش مصنوعی

Rust در حال آزمودن تغییری ظاهراً کوچک با دامنه‌ای بزرگ در طراحی زبان است: آرگومان‌هایی که اکنون در یک tuple قرار می‌گیرند، بتوانند هنگام فراخوانی به‌صورت جداگانه نوشته شوند. این آزمایش که «splat» نام دارد، عمدتاً برای اتصال‌های FFI طراحی شده است؛ جایی که APIهای زبان‌هایی مانند C++ معمولاً چند تابع هم‌نام با فهرست پارامترهای متفاوت دارند.

امروز Rust می‌تواند با traitها و tupleها نوعی overload را شبیه‌سازی کند. برای نمونه، یک تابع کمکی می‌تواند یک tuple از آرگومان‌ها بگیرد و برای (f64, f64) و (f64, f64, f64) پیاده‌سازی trait داشته باشد؛ اما فراخواننده باید شکل ناخوشایندی مانند hypot((2.0, 3.0, 6.0)) بنویسد. آزمایش شبانه‌روزی اجازه می‌دهد همین تابع با شکل hypot(2.0, 3.0, 6.0) فراخوانی شود، در حالی که inference نوع و بررسی trait همچنان بر سازوکارهای موجود Rust تکیه دارند.

این تفاوت مهم است. Splat هنوز یک overload resolver به سبک C++ نیست. طراحی فعلی از پارامتری tupleمانند یا generic استفاده می‌کند که با صفت داخلی #[rustc_splat] مشخص شده و برای فعال‌سازی آن باید از #![feature(splat)] استفاده کرد. شکل فراخوانی آشناتر می‌شود، اما پرسش بنیادین این است که آیا type system Rust می‌تواند هنگام رقابت چند overload خارجی، همچنان مرجع تصمیم‌گیری باقی بماند.

مقاله پیگیری این مرز را روشن می‌کند. پرسش‌های حل‌نشده شامل انسجام traitها، overloadهای هم‌پوشان، امکان افزودن overload توسط هر crate، رفتار آرگومان‌های اختیاری، ABIهای مجاز و شیوه اختصاص symbolهای متمایز به توابع هم‌نام است. این‌ها صرفاً مسائل ظاهری نیستند: یک call expression راحت تنها زمانی ارزشمند است که پیاده‌سازی را بدون ابهام انتخاب کند و خطاهایی تولید کند که توسعه‌دهنده بتواند به آن‌ها اعتماد کند.

بنیاد Rust این کار را فراتر از C++ می‌داند و آن را نوعی نقشه‌برداری برای زبان‌ها و سبک‌های مختلف FFI توصیف می‌کند. هدف، جمع‌آوری شواهد درباره این است که قواعد فعلی Rust کجا با قراردادهای زبان‌های خارجی سازگار می‌شوند، کجا مقاومت می‌کنند و کدام بخش‌ها در آینده باید در macro، ابزارها یا خود compiler قرار گیرند. طرح احتمالی #[overload] فقط یک امکان آینده است، نه پیشنهادی پذیرفته‌شده.

برای توسعه‌دهندگان Rust، توصیه عملی محدود است. سازندگان toolchainهای مشترک Rust و C++ و مشارکت‌کنندگان compiler می‌توانند nightlyهای منتشرشده از ۳۱ ژوئیه ۲۰۲۶ به بعد را آزمایش کنند، حالت‌های مبهم و cross-crate را بررسی کنند و خطاها را از مسیرهای ارتباطی interop پروژه گزارش دهند. تیم‌های محصول باید این قابلیت را ابزار بررسی طراحی بدانند، نه مقصد مهاجرت؛ زیرا هنوز قابلیتی در stable Rust وجود ندارد و ماندگاری syntax فعلی تضمین نشده است.

ملاحظه تحریریه: splat یک آزمایش ناقص در Rust شبانه‌روزی و بدون RFC است. syntax و رفتار آن ممکن است به‌طور اساسی تغییر کند یا حذف شود؛ بنابراین مثال‌های این مقاله نباید به‌عنوان راهنمای production یا stable Rust استفاده شوند.

برچسب‌هاRustFFIاتصال C++Compiler
منابع مستند۳ مرجع
  1. [۰۱]Rust Function Overloading - Call for Experimentationblog.rust-lang.org
  2. [۰۲]Experimenting with Function Overloading in Rust: Why It Mattersrustfoundation.org
  3. [۰۳]Tracking Issue for argument splatting lang experiment #153629github.com
خواندنی بعدی

خبرخوان را در ایمیل بگیرید

هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.

خوراک RSS در دسترس · بدون هرزنامه