TS تحلّ مشكلة "كود يعمل على أي نوع" بالـ generics، ثم — عند الترجمة إلى JS — تمحو كل أثر لها. لا T يبقى وقت التشغيل، لا فحص، لا شيء؛ التوقيع كان عقدًا بين المطوّرين فقط. Rust لا تملك هذه الرفاهية: لا يوجد "وقت ترجمة إلى لغة أخرى تُمحى فيه الأنواع" — الناتج كود آلة مباشرة، يعمل بلا أي مفسّر يحمل معلومات الأنواع معه وقت التشغيل. فكيف تكتب "دالة تعمل على أي نوع" في لغة كهذه؟

الدرس ١: صمّم آلية العمومية بنفسك

اللغز التأسيسي

int cmp_int(const void *a, const void *b) {
    return (*(const int *)a - *(const int *)b);
}
qsort(arr, n, sizeof(int), cmp_int);

الحل: Rust تختار (أ) افتراضيًا — Monomorphization

fn largest<T: PartialOrd>(list: &[T]) -> &T {
    let mut m = &list[0];
    for x in list {
        if x > m { m = x; }
    }
    m
}

largest(&[3, 7, 2]);           // يستدعي نسخة i32
largest(&["a", "z", "m"]);     // يستدعي نسخة &str

<T: PartialOrd> يعني: T معامل — لكن معامل نوع، لا قيمة (فرق جوهري عن generics في TS التي تتعامل مع النوع كمتغيّر منطقي وقت الترجمة فقط؛ هنا هو نفسه لكن الأثر يمتد لما بعد الترجمة). PartialOrd قيد (bound): "أي نوع T طالما يدعم < و>". بلا القيد، x > m لن يُترجَم — المترجم يرفض أن يفترض قدرة لم تُثبت. (قارن: void* في C يفترض كل شيء ولا شيء في آن؛ القيد هنا يفترض بالضبط ما أثبتّه، لا أكثر.)

عند الترجمة، يفحص المترجم كل موضع استُدعيت فيه largest فعليًا، ويولّد نسخة آلة منفصلة كاملة لكل نوع فعلي: كأنك كتبت largest_i32 و largest_str بيدك. هذا اسمه monomorphization (من "poly-morphic" [أشكال كثيرة] إلى "mono-morphic" [شكل واحد] لكل نسخة). النتيجة: صفر تكلفة إضافية وقت التشغيل — لا void*، لا فحص نوع، لا طبقة تنسيق. الكود المولَّد للنسخة i32 مطابق تمامًا لما كنت ستكتبه يدويًا لو صُمّمت الدالة لـi32 فقط منذ البداية. هذا بالحرف تعريف zero-cost abstraction (شعار Bjarne Stroustrup الأصلي لـ C++): ما لا تستعمله لا تدفع ثمنه، وما تستعمله لا يمكنك كتابته يدويًا بكفاءة أعلى.

الثمن — ولكل شيء ثمن — هو حجم الملف التنفيذي (code bloat): استعملتَ largest مع خمسة أنواع؟ خمس نسخ من الآلة الفعلية تعيش في الثنائي. هذا ثمن معلن، لا مخفي، ويمكنك رؤيته بأدوات مثل cargo bloat إن أردت.

قارنها الآن بـ TS: هناك، T معلومة تُمحى بالكامل قبل أن يعمل أي شيء — لا نسخ، لا تكاثر، لكن أيضًا لا حماية وقت التشغيل (تذكّر ledger TS نقطة ٩: any/erasure). هنا: لا محو على الإطلاق — بل تكاثر، والحماية موجودة لأن كل نسخة مُتخصَّصة فعليًا ومفحوصة وقت الترجمة. اتجاهان معاكسان تمامًا لحل نفس المشكلة الظاهرية.

الدرس ٢: Trait — العقد الذي يحرس القيد

trait مقابل C وTS

trait Shape {
    fn area(&self) -> f64;
    fn name(&self) -> &str { "shape" }   // تطبيق افتراضي — مسموح
}

struct Circle { r: f64 }
impl Shape for Circle {
    fn area(&self) -> f64 { std::f64::consts::PI * self.r * self.r }
}

trait أقرب لـ interface في TS، لكنه مصدر القيود (bounds) التي رأيتها أعلاه: T: PartialOrd تعني "أي T طبَّق trait PartialOrd". بعقلية C: هذا أشبه بجدول دوال (vtable) تُعرِّفه صراحةً بدل تمرير مؤشر دالة خامًا كما في qsort — لكن هنا المترجم يتحقق وقت الترجمة أن كل نوع يدّعي تطبيق Shape يوفّر فعليًا area، بالتوقيع الصحيح تمامًا، لا اجتهادًا.

لاحظ توقيع area(&self): هذا القرار نفسه الذي اتخذته يدويًا في توقيعات الإقليمين ٠١ و٠٢ — استعارة، أم استعارة حصرية، أم تمليك؟ — لكنه الآن مكتوب كجزء من تعريف الطريقة (method) نفسها بدل معامل عادي:

derive — حين يصبح التطبيق ميكانيكيًا

في الإقليم ٠١ كتبتَ impl Drop for Noisy بيدك — منطق حقيقي، لا يمكن أتمتته. لكن طلبات كثيرة ميكانيكية بحتة: "قارن كل الحقول"، "انسخ كل حقل عميقًا"، "اطبع الحقول بصيغة تصحيح". اكتب واحدة بيدك لتشعر بالتكرار:

struct Point { x: i32, y: i32 }
impl PartialEq for Point {
    fn eq(&self, other: &Self) -> bool { self.x == other.x && self.y == other.y }
}

الآن قارن بالسكّر:

#[derive(Debug, Clone, PartialEq)]
struct Point { x: i32, y: i32 }

derive يولّد نفس الكود الميكانيكي آليًا. هذا مثال idiom طبقة ثانية: لماذا يكتب أهل اللغة #[derive(...)] في كل مكان تقريبًا؟ لأنهم جرّبوا كتابتها يدويًا مرة واحدة (كما فعلتَ للتو)، ورفضوا التكرار.

Static Dispatch مقابل Dynamic Dispatch

عُد لـ qsort: مؤشر الدالة cmp الذي مررته هو dynamic dispatch يدوي وخام — القرار "أيّ دالة تُنادى" مؤجَّل لوقت التشغيل، عبر مؤشر. Rust تعطيك الخيار نفسه، لكن مُطعَّمًا بالأمان، إلى جانب الخيار الافتراضي الأسرع:

fn total_area_generic(shapes: &[impl Shape]) -> f64 {   // static — monomorphized
    shapes.iter().map(|s| s.area()).sum()
}

fn total_area_dyn(shapes: &[Box<dyn Shape>]) -> f64 {   // dynamic — vtable
    shapes.iter().map(|s| s.area()).sum()
}

• Static (impl Trait أو <T: Shape>): نفس monomorphization أعلاه. سريع كحدّه الأقصى، لكن يجب معرفة النوع الفعلي وقت الترجمة — قائمة أشكال من نوع واحد فقط في كل استدعاء فعلي.
• dyn Shape (trait object): الآن يمكنك تكديس أنواع مختلفة معًا: Vec<Box<dyn Shape>> تحوي دوائر ومربعات معًا بلا مشكلة. الثمن: كل قيمة dyn Shape هي fat pointer — مؤشر للبيانات + مؤشر لجدول دوال (vtable) — واستدعاء area() يقفز عبر الجدول وقت التشغيل. هذا بالضبط مؤشر الدالة في qsort، مع فارقين: الأمان (لا يمكن خلط جدول نوع بمؤشر بيانات نوع آخر — المترجم يربطهما معًا دومًا) والتنظيم (الجدول يُبنى تلقائيًا من تطبيقك للـ trait، لا تكتبه يدويًا).

الجدول الكامل، حتى تحسم بنفسك حين تصمّم:

الألغاز

الخلاصة

• العقدة الجديدة: generics تُحل بالتكاثر (monomorphization) لا بالمحو — نقيض TS تمامًا في الاتجاه، وتوأمها في الهدف (كتابة كود مرة واحدة). trait هو العقد الذي يحرس القيد، ومنه ينبثق خيار Static مقابل Dynamic dispatch — نسخة آمنة ومنظَّمة من void* + مؤشر دالة الذي عرفته في C.
• الوصلة للخلف: self/&self/&mut self ليست صياغة جديدة — إنها توقيعات الملكية من ٠١-٠٢ وقد انضمّت لنوعها. وexhaustiveness من ٠٣ ونظام الأنواع هنا كلاهما يخدم نفس الهدف: إثبات وقت الترجمة بدل الأمل وقت التشغيل.
• الوصلة للأمام: كل الأمثلة أعلاه استعملت &self، &T، &[T] — استعارات تعيش داخل جسم دالة واحدة قصيرة. ماذا لو أراد struct نفسه أن يحوي مرجعًا كحقل، يعيش معه؟ جرّب الآن، بسرعة، قبل أن تكمل:

struct Highlight {
    text: &str,   // جرّب هذا فعليًا
}