Сайт автора кстати http://zed.karelia.ru/go.to/feed.back/other , судя по всему TG у него нет)

обратный цикл без целочисленных знаковых типов (i32, isize т.д.):

// все типы начиная с u1.
const steps: u32 = 5;
// Работает в диапазоне [1, maxInt]

var i = steps - 1;
while (i < steps) : (i -℅= 1) {
    // Что-то делаем
}

Примерная логика такая:
i = 4
i = 3
i = 2
i = 1
i = 0
(переполнение) i = maxInt
maxInt >= steps, цикл стопается.

На большинстве (емнип?) архитектур без потерь производительности.

или так (диапазон тот же):

С новым годом всех!!! (у меня +6)
🦀🦀🦀 🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊⚡

https://github.com/spanzeri/vkguide-zig

Порт vkguide.dev на Zig

https://ziglang.org/news/2024-financials/

Финансовый отчёт за 2023 + призывают пожертвовать ещё)
#upstream

Тама стрим недавно закончилсч, с планом на 2024 год: https://www.youtube.com/watch?v=5eL_LcxwwHg

#upstream #видео

Если кто-то будет в Ульяновске / Питере, то я буду выступать с докладом про Зиг и эмулятор для MMORPG на Стачке 🙂

https://nastachku.ru

Даешь Зиг в массу :3

Бо‌льшую часть компилятора хотят вынести в отдельные файлы и компилировать по мере надобности прямо во время работы. Первым делом выносят zig fmt и zig reduce.

По идее, это позволит легче контрибутить в сам проект или патчить после установки (т.к. файлы прямо тут, в папке lib/), уменьшить размер всего набора пакетов Zig и уменьшить время сборки (хотя по сути оно будет просто „размазано” в рантайме, но учитывая что не весь код используется для компиляции, доожно быть несущественно).

Из того, что должны оставить: компиляцию нативным бэкендом и запуск дочерных процессов. Грубо говоря, если вы скачиваете Zig для x86_64 на Линукс какой-нить, в самом исполняемом файле "zig" будет только x86_64 backend и этот самый запуск, для Hello World этого хватит.
Но если вы захотите сделать zig fmt или скомпилировать с помощью aarch64 backend, он скомпилирует эти файлы в lib/ и будет уже ими управлять. Т.к. система кэширования уже есть, одного раза должно хватить (пока не измените там код).

Для обычного пользователя ничего не поменяется (те же самые команды и т.д.), но первая компиляция станет чуть-чуть медленнее.

#upstream

Полностью переработанный autodoc, там слишком много чего технического поменяли, так что пишу только то, что полезно самим пользователям.
https://github.com/ziglang/zig/pull/19208

Для документации стандартной библиотеки:
* До: Собирается за 13.3 секунды, ест гигабайт памяти, выхлоп 47 мегабайт.
* После: Собирается за 24 миллисекунды, ест 90 мегабайт памяти, выхлоп 12 мегабайт.

И ещё закрывает 9 issues. Из минусов: теперь требует поддержку WebAssembly в браузере, т.к. основная логика написана на Zig, который компилируется потом в WASM. Ну и часть нагрузки теперь перенесена с сборщика на браузер клиента. Зато несёт больше интерактивности.

> lib/docs/ziglexer.js was an implementation of Zig language tokenization in JavaScript, despite Zig already exposing its own tokenizer in the standard library. When I saw this added to the zig project, a little part of me died inside.

#upstream

Zig defer Patterns

#блоги

Думаю, большинство уже слышало про это, кроме errdefer comptime unreachable

https://github.com/ziglang/zig/pull/19459

Черновой запрос на слияние, добавляющий поддержку синтаксиса "labeled continue inside a switch", т.е. computed goto (таблицы переходов). Пример кода (немного упрощено, с новых тестов):

const std = @import("std");

const Tag = enum {
    a,
    b,
    c,
};

pub fn main() !void {
    const tag: Tag = .a;
    const result = brk: switch (tag) {
        .a => continue :brk .c, // 1
        .b => break :brk false, // 3
        .c => continue :brk .b, // 2
    };

    try std.testing.expect(result == false);
}

В этом примере, switch с меткой brk сначала перейдёт в ветку .a, которая говорит "продолжить и перейти в ветку .c*, которая тоже говорит "продолжить и перейти в ветку .b", где блок прерывается.

#upstream

Для понимания можно ещё проще пример сделать:

const bit: u1 = 0;

label: switch (bit) {
    0 => continue :label 1,
    1 => continue :label 0,
}

Тут получился обычный бесконечный цикл, где switch скачет от 0 до 1 и обратно.

Автор планирует добавить поддержку чисел, булевых значений, перечислений (enum) и помеченных объединений (tagged union), но не знает, нужно ли поддерживать error values.

Чем это отличается от обычного:

var tag: Tag = .a;
const result = brk: while (true) switch (tag) {
    .a => {
        tag = c;
        continue :brk;
    },
    .b => break :brk false,
    .c => {
        tag = b;
        continue :brk;
    },
};

В варианте с while-switch таблицы переходов может и не появиться, нет гарантий, это зависит от оптимизатора.
А в варианте с labeled continue она будет гарантированно создана во всех режимах сборки (в том числе Debug).

Ну и размер самой таблице зависит от того, какой тип принимает switch, т.е. в u8 или enum(u8) может быть до 255 вхождений, а в u16 уже 65 535.

Это всё включено в размер сгенерированного кода, поэтому при необдуманном пользовании бинарник может сильно распухнуть (ну как я понял), а при обдуманном хорошо так поднять производительность.

Я тут пока лазил в кишках компилятора (с @field химичу), заметил одну вещь: пропускать указатель (т.е. писать "ab.cc" вместо "ab.*.cc") можно не только в полях, но и в декларациях (типы добавил для наглядности)

const std: type = @import("std");
const std_ref: *const type = &std;

test {
    _ = std_ref.ArrayList(u8).init(std_ref.testing.allocator);
}

ZLS при этом молчит (ломается походу) и не даёт автокомплит для std_ref.

Сначала подумал, что у себя в форке что-то там сломал, но на мастер ветке то же самое.

Тот самый Алекс Кладов ака matklad акак один из разрабов rust-analyzer, TigerBeetle и т.д., чьи посты иногда тут репостятся)