پروژه Beyond the &؛ تلاش تیم زبان Rust برای هم‌سطح‌سازی اسمارت‌پوینترها با رفرنس‌های توکار

زبان برنامه‌نویسی Rust به خاطر سیستم مدیریت حافظه و بررسی‌کننده وام‌گیری (borrow checker) شهرت دارد. این زبان از انواع اسمارت‌پوینترها (Smart Pointers) در کتابخانه استاندارد و توسط کاربران پشتیبانی می‌کند، اما برخی عملیات که با رفرنس‌های توکار (built-in references) ممکن است، روی اسمارت‌پوینترهای سفارشی قابل انجام نیستند. تایلر مندری (Tyler Mandry)، سرپرست تیم زبان Rust، در کنفرانس RustConf درباره پروژه‌ای به نام Beyond the & صحبت کرد که هدف آن رفع این محدودیت‌هاست.

ریشه مشکل و چالش Borrow Checker

برای درک مسئله، فرض کنید برنامه‌ای می‌خواهد داده‌های داینامیک را در یک HashMap کش کند. اگر از رفرنس‌های معمولی مثل &mut RenderState استفاده کنید، borrow checker به خوبی تشخیص می‌دهد که فیلدهای مختلف ساختار (مانند cache و template) از هم مجزا هستند و می‌توان همزمان به آن‌ها دسترسی داشت.

اما به محض اینکه بخواهید این ساختار را درون یک Mutex قرار دهید تا بین تردها امن باشد، همه‌چیز تغییر می‌کند:

let state: MutexGuard<'_, RenderState> = state.lock().unwrap();
let entry = state.cache.entry(name.to_string());
// کامپایلر خطا می‌گیرد زیرا متغیر state به شکل مبهمی وام گرفته شده است
entry.or_insert_with(|| {
    Arc::new(state.template.replace("$name", name))
}).clone();

در اینجا، borrow checker دیگر نمی‌تواند تفکیک فیلدها را پشت MutexGuard تشخیص دهد و به دلیل احتمال وقوع Data Race، کامپایلر برنامه را رد می‌کند. راه‌حل فعلی، بازگرداندن و ساخت دوباره رفرنس با دستوراتی مثل &mut *state.lock().unwrap() است که کدی غیرشهودی تولید کرده و منحنی یادگیری Rust را دشوارتر می‌کند.

راه حل: انتشار مفهوم Place به کدهای کاربر

تیم زبان Rust با الهام از کارهای Nadrieril و Benno Lossin به دنبال این است که مفهوم داخلی کامپایلر یعنی Place (موقعیت‌هایی که مقادیر از آن‌ها خوانده یا نوشته می‌شوند، مشابه lvalues در زبان C) را به کدهای سطح کاربر بیاورد.

ایده اصلی ایجاد یک نوع Handle برای هر اسمارت‌پوینتر است. کامپایلر به‌طور خودکار Handleها را برای نمایش Placeهای ارجاع‌داده‌شده می‌سازد. سپس نویسندگان کتابخانه‌ها می‌توانند با پیاده‌سازی تریت‌های جدید، رفتار borrow checker را نسبت به این پوینترها سفارشی کنند:

• WritePlace: نحوه نوشتن در یک Place را تعیین می‌کند.
• ReadPlace: نحوه خواندن از پوینتر را کدگذاری می‌کند.
• ProjectPlace: نحوه تبدیل یک Place حاوی ساختار به یک Place حاوی یکی از فیلدهای آن را مشخص می‌کند (مانند تبدیل MutexGuard<RenderState> به MutexGuard<String>).
• BorrowPlace: نحوه ایجاد یک اسمارت‌پوینتر جدید که یک Place را قرض می‌گیرد، دقیقا مشابه کارکرد & برای رفرنس‌های داخلی.

مثالی از پیاده‌سازی تریت BorrowPlace برای رفرنس‌های داخلی نشان می‌دهد که این مکانیزم تا چه اندازه یکپارچه است:

unsafe impl<'a, T> BorrowPlace<&'a T> for RefHandle<'a, T> {
    const ACCESS: AccessKind = AccessKind::Shared;
    type Timing = Lifetime<'a>;
    const SAFE: bool = true;
    unsafe fn borrow(self) -> &'a T {
        unsafe { &*self.ptr.as_ptr() }
    }
}

چرا این تغییر اهمیت دارد؟

با این تغییرات عمده، مزایای زیر نصیب توسعه‌دهندگان می‌شود:

• تطبیق‌پذیری بالا: اسمارت‌پوینترهای سفارشی دقیقاً رفتاری مشابه رفرنس‌های توکار خواهند داشت.
• امکان Pattern Matching: توسعه‌دهندگان می‌توانند روی مقادیر پشت اسمارت‌پوینترها نیز الگویابی (pattern matching) انجام دهند، بدون اینکه نیاز به dereference کردن دستی داشته باشند.
• ترکیب‌پذیری (Composability): از آنجا که این طراحی مستقیماً بر اساس نحوه درک کامپایلر از کد پیاده‌سازی شده، به خوبی با سایر بخش‌های زبان ترکیب می‌شود.

این پروژه در حال حاضر در مرحله پروتوتایپ قرار دارد و تیم زبان از توسعه‌دهندگان دعوت کرده است تا مستندات آن را بررسی کرده و بازخوردهای خود را درباره اسمارت‌پوینترهای با رفتارهای خاص ارائه دهند.