لقد كنت أتعلم Zig لمشروع تطوير اللعبة الخاص بي، اقرأ المزيد عنه هنا. هذه هي انطباعاتي الأولية (الإيجابية في الغالب) عن اللغة، والتي تأتي من تجربتي الأخيرة في JS/TS.

معالجة الأخطاء

الأخطاء هي قيم - من الشائع جدًا في هذه المرحلة أن الاستثناءات ليست الأفضل. فهي تنشئ تدفق تحكم مخفيًا، ولا يمكن حتى الإعلان عنها في JavaScript؛ مما يجعل تطبيقاتك غير مستقرة أكثر بكثير.

يستخدم Zig تعدادات الأخطاء والسكر النحوي اللطيف لمعالجة الأخطاء بسهولة وممتعة. على سبيل المثال :

fn failingFunction() error{MyError}!void {
    return error.MyError;
}

pub fn main() !void {
    try failingFunction();
}

في الكود أعلاه نعلن عن خطأ MyError (يمكن أيضًا القيام بذلك بشكل منفصل) ونعيده.
تعني المحاولة "إذا أدى هذا إلى إرجاع خطأ، فأعده هنا" كما في:

failingFunction() catch |err| return err;

أعتقد أن هذا النهج يمثل مزيجًا رائعًا وينقذنا من حالة الـ if (err != nil) التي لا نهاية لها في Go Land.

ميزات أخرى:

• الأخطاء صريحة، يجب الإعلان عن جميع الأنواع ومعالجتها
• تتم المعالجة في ذلك الوقت وهناك، وليس على مستوى الكتلة
• بفضل التقاط الحمولة، تتم كتابة الأخطاء بشكل صحيح وإكمالها تلقائيًا، مما يجعل من السهل استخدام شيء مثل تعبير التبديل.

بناء الجملة !void - ! يتم استخدامه لإنشاء اتحاد بين نوع الإرجاع وأنواع الأخطاء. يدعم Zig عدم إضافة أي أخطاء قبل !، والذي من المفترض أن يؤدي إلى إنشاء اتحاد لجميع الأخطاء التي ترجعها بالفعل من الوظيفة.

من الناحية العملية، أجد أن بناء الجملة هذا غير مفيد. على الأقل من خلال تجربتي في IDE، لم أحصل على أي تحسس في هذه الحالة، وهذا يجعل الوظيفة أقل وضوحًا. فقط أخبرني بما ستعود إليه!
أرى أنه مفيد فقط في الوظيفة الرئيسية ().

التقاط الحمولة

أنت تعرف كيف أنه في TS قد يكون لديك نوع مثل الرقم | غير محدد؟ يمكنك استخدام منطق if أو بعض المنطق لتضييق نطاق النوع إلى ما تحتاجه، ويعرض TS تلقائيًا النوع الجديد بشكل صحيح.
على الرغم من سهولة الأمر، إلا أن هناك مشاكل في هذا النهج:

• إذا كان من الممكن تغيير الأنواع خلال الوظيفة، فمن الصعب متابعتها
• في بعض الحالات، لا يزال يتعين عليك إجراء عملية التمثيل

في Zig، يمكنك القيام بذلك من خلال "التقاط الحمولة". يمكنك "التقاط" ويعرف أيضًا باسم إنشاء متغير جديد غير قابل للتغيير بالنوع الناتج. على سبيل المثال:

const maybe_num: ?usize = 10; // `?` Means it can be `null`

if (maybe_num) |num| {
    // Use num
}

من الواضح جدًا ما يحدث! علاوة على ذلك، فإن المتغير غير قابل للتغيير، ولكن إذا كنت بحاجة حقًا إلى تغييره، فيمكنك التقاط مؤشر للقيمة بدلاً من ذلك.

ومن الجدير بالذكر أيضًا أنه يمكن استخدام هذه الآلية في جميع أنحاء اللغة، بما في ذلك: for، وswitch، وcatch، وما إلى ذلك.

خدع كومبتيم

من المسلم به أنني لم أفهم بعد الإمكانيات الكاملة لوقت العمل. ولكن باختصار، يمكنك تشغيل التعليمات البرمجية العادية أثناء التجميع. يمكنك إنشاء وظائف كاملة يتم استخدامها فقط خلال هذا الوقت، ويمكنك إرجاع أخطاء الترجمة إذا لزم الأمر.

إنها تناسب Zig جيدًا، لأنها لغة مرنة جدًا. الأنواع الزوجية هي قيم، مما يعني أنه يمكنك إنشاء الأنواع وتغييرها والحصول على معلومات حولها (خاصة في وقت التشغيل).

مثال أساسي على ذلك من دليل Zig:

كونست أ = 5؛ // عندما لا يتم تحديد نوع الرقم، فإنه يكون افتراضيًا comptime_int const b: if (a const a = 5; // When a number type isn't specified, it defaults to comptime_int const b: if (a تجربة المحرر

أنا أستخدم VSCode مع البرنامج الإضافي Zig الرسمي (الذي يستخدم zls). الذكاء والأخطاء التي أراها في المحرر تترك الكثير مما هو مرغوب فيه.

"السلوك غير القانوني الذي يمكن اكتشافه" والمعروف أيضًا باسم الأشياء غير القانونية التي تؤدي إلى خطأ في الترجمة لا يتم عرضها عادةً في المحرر. على سبيل المثال:

أرقام الأعداد = [3]u8{ 2, 1, 3 }; _ = الأعداد[4]; // فهرس خارج الحدود خطأ

const a = 5; // When a number type isn't specified, it defaults to comptime_int
const b: if (a أنا أستخدم إصدار الفرع الرئيسي 0.14 (مطور)، إذا كان من المفترض أن يعمل، فأخبرني بذلك في التعليقات!