Я изучаю zig для своего проекта по разработке игр, подробнее об этом читайте здесь. Это мои первоначальные (в основном положительные) впечатления от языка, основанные на недавнем опыте работы с JS/TS.

Обработка ошибок

Ошибки — это ценности — На данный момент довольно популярно мнение, что исключения — это не самое лучшее. Они создают скрытый поток управления, а в JavaScript их даже нельзя объявить; что делает ваши приложения намного более нестабильными.

Zig использует перечисления ошибок и приятный синтаксический сахар для простой и увлекательной обработки ошибок. Например :

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

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

В приведенном выше коде мы объявляем ошибку MyError (это также можно сделать отдельно) и возвращаем ее.
Try означает «если это возвращает ошибку, верните ее сюда», например:

failingFunction() catch |err| return err;

Я считаю, что этот подход является отличным сочетанием и спасает нас от бесконечных if (err != nil) в Goland.

Другие интересные моменты:

• Ошибки являются явными, все типы должны быть объявлены и обработаны
• Обработка осуществляется прямо здесь и сейчас, а не на уровне блока
• Благодаря захвату полезной нагрузки ошибки вводятся правильно и автозаполняются, что позволяет легко использовать что-то вроде выражения переключения.

Синтаксис !void - ! используется для создания объединения между типом возвращаемого значения и типами ошибок. Zig поддерживает отсутствие каких-либо ошибок перед !, что должно создавать объединение всех ошибок, которые вы фактически возвращаете из функции.

На практике я считаю этот синтаксис бесполезным. По крайней мере, учитывая мой опыт работы с IDE, я не вижу в этом случае никакого смысла, и это делает функцию менее понятной. Просто скажи мне, что ты собираешься вернуть!
Я вижу, что это полезно только для функции main().

Захват полезной нагрузки

Вы знаете, что в TS у вас может быть такой тип, как число | неопределенный? Вы можете использовать if или другую логику, чтобы сузить тип до того, что вам нужно, и TS автоматически правильно отобразит новый тип.
Хотя это просто, у этого подхода есть проблемы:

• Если типы могут меняться в рамках функции, за этим труднее следить
• В некоторых случаях все равно придется делать кастинг

В Zig это можно сделать с помощью функции «Захват полезной нагрузки». Вы можете «захватить», то есть создать новую неизменяемую переменную с результирующим типом. Например:

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

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

Совершенно ясно, что происходит! Более того, переменная является неизменяемой, но если вам действительно нужно ее изменить, вместо этого вы можете захватить указатель на значение.

Также стоит отметить, что этот механизм можно использовать во всем языке, в том числе: for, switch, catch и т. д.

Комптаймовые махинации

Признаюсь, я еще не осознал всех возможностей Comptime. Короче говоря, вы можете запускать обычный код во время компиляции. Вы можете создавать целые функции, которые будут использоваться только в это время и при необходимости возвращать ошибки компиляции.

Он вполне подходит Зигу, потому что это очень податливый язык. Даже типы являются значениями, то есть вы можете создавать, изменять и получать информацию о типах (особенно в Comptime).

Простой пример из Zig Guide:

const a = 5; // When a number type isn't specified, it defaults to comptime_int
const b: if (a 




  
  
  Опыт редактора


Я использую VSCode с официальным плагином Zig (который использует zls). Интеллектуальность и ошибки, которые я вижу в редакторе, оставляют желать лучшего.

"обнаруживаемое незаконное поведение" то есть незаконные действия, которые могут привести к ошибке компиляции, обычно не отображаются в редакторе. Например:



const nums = [3]u8{ 2, 1, 3 };
_ = nums[4]; // Index out of bounds error




Я использую версию основной ветки 0.14 (dev), если она должна работать, дайте мне знать в комментариях!