راست ۱.۹۹، `Box::leak` را به یک نقطه برای بازبینی مالکیت تبدیل می‌کند

نسخهٔ ۱.۹۹.۰ راست که در اول اکتبر منتشر شد، بدون تغییر معنای زبان یک نشانهٔ مهم دربارهٔ مالکیت اضافه می‌کند: مستندات کتابخانهٔ استاندارد اکنون توصیه می‌کنند حافظه‌ای را که با Box::leak به‌دست آمده، از طریق تبدیل دوباره به اشاره‌گر و سپس آزادسازی، بازیابی نکنید.

Box::leak یک Box<T> را به مرجعی تبدیل می‌کند که می‌توان طول عمر آن را افزایش داد؛ بنابراین برای داده‌هایی که عمداً باید تا پایان فرایند باقی بمانند، مانند پیکربندی سراسری یا رجیستری‌ها، کاربرد دارد. خطر زمانی ایجاد می‌شود که برنامه از آن به‌عنوان راهی موقت برای عبور از محدودیت مالکیت استفاده کند، بعداً از طریق اشاره‌گر خام مالکیت را بازسازی کند و تخصیص را آزاد سازد.

تیم انتشار راست می‌گوید چنین الگوی رفت‌وبرگشتی ممکن است با بهینه‌سازی‌های فعلی و آیندهٔ کامپایلر تعامل نامناسب داشته باشد؛ این نگرانی با نزدیک‌شدن تثبیت تخصیص‌دهنده‌های سفارشی مهم‌تر می‌شود. به همین دلیل راست ۱.۹۹ در مواردی که تخصیص باید در آینده آزاد شود، Box::into_raw یا Box::into_non_null را پیشنهاد می‌کند. این APIها انتقال مالکیت را صریح نگه می‌دارند و تخصیص را به‌عنوان حافظه‌ای که قرار است برای طول عمر یک مرجع نشت کند، معرفی نمی‌کنند.

برای نویسندگان کتابخانه، پرسش عملی دیگر فقط «آیا این کد کامپایل می‌شود؟» نیست؛ بلکه باید پرسید «آیا این تخصیص واقعاً قرار است دائمی باشد؟» کدهای ناامن و لایه‌های FFI را برای وجود Box::leak، بازسازی مالکیت از اشاره‌گر خام و آزادسازی دستی بررسی کنید. اگر آزادسازی بخشی از طراحی است، از تبدیل‌هایی استفاده کنید که مالکیت را حفظ می‌کنند و قرارداد تخصیص‌دهنده و آزادسازی را مستند سازید.

یک نکتهٔ احتیاطی مهم است: راست ۱.۹۹ راهنمای مستندات را تغییر می‌دهد، نه معنای زبان را. نشت عمدی حافظه همچنان می‌تواند یک انتخاب طراحی معتبر باشد؛ هشدار متوجه الگوهایی است که ابتدا حافظه را نشت می‌دهند و بعداً قصد آزادسازی آن را دارند.