Пока есть время исправить ошибку с единственным типом usize и внедрить улучшения в сам язык перед 1.0, думаю стоит воспользоваться.

К примеру на Си у них есть хедер с такими функциями:
cheri_address_get, cheri_base_get, cheri_address_set и т.д.

На Zig это можно было бы представить так же, как поля для срезов ptr и len, только для указателей:

var ptr: [*]u32 = ...;
ptr.address += 1;
ptr.permissions = .read_only;

Другой вариант: в Си есть паттерн с containerof, где из указателя к полю структуры получают указатель ко всей структуре.

В обычных CHERI C компиляторах указатель на поле структуры автоматом получит более точный и меньший диапазон, чем указатель к структуре. Так как указатели невозможно "расширить" обратно, такой прикол не сработает. Для этих случаев есть аттрибуты, которые контролируют это ограничение (no subobject bounds)

В Zig для этого есть одна встроенная функция @fieldParentPtr. Компилятор Zig может просто проверять, используется ли она в каком-то месте для какой-то структуры. Если нет, включаем сжатие границ для них, если есть, отключаем.

а да, и ещё addrspace(.generic) придётся переделать или удалить, но вроде как AVR и SPIR-V мейнтейнеры и так хотят убрать его

потому что в гибрид моде у обычных указателей будет addrspace 0 (как обычно на x86-64), а у capabilities 200, чтобы старый код мог работать дальше на CHERI системах (например, закрытые программы или библиотеки, которые нельзя пересобрать), и рантайм мог отличать его от нового

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

[RFC] Libc++ taking a dependency on Boost.Math for the C++17 Math Special Functions

У libc++ (стандартной библиотеки C++ от LLVM) может появиться новая зависимость Boost.Math, которая позволит докончить поддержку C++17 в коде.

Почти все соглашаются и поддержиают это решению, но Эндрю говорит это помешает сильно для zig и zig c++:

This is apocalyptic for us. We, and our users would strongly prefer missing C++17 features than a Boost.Math dependency.

If LLVM moves forward with this, we will very likely patch it out.

Правда, весомых технических причин он не указал, так что люди не поняли...

https://codeberg.org/breadtom/expozig

Альтернативный компилятор для Zig на Си. Автор хочет другой способ бутстрапинга сделать, без WASM файлов, от Си сразу к Zig

https://github.com/akhildevelops/cudaz

Библиоткеа для работы с CUDA

#библиотеки

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

Эндр подчищает ring buffers в стандартной библиотеке (их в сумме 4, один он убирает в другом ПР и один тут).

BoundedArray он так и не полюбил :( опять хочет его удалить.

#upstream

10 лет с момента создания Zig:

https://github.com/ziglang/zig/commit/8e08cf4bec80b87a7a22a18086a3db5c2c0f1772

Старый Hello World 2015 года:

export executable "hello";

#link("c")
extern {
    fn printf(__format: *const u8, ...) -> i32;
    fn exit(__status: i32) -> unreachable;
}

export fn _start() -> unreachable {
    printf("Hello, world!\n");
    exit(0);
}

Влияние Rust здесь хорошо видно.

0.1.0 (октябрь 2017):

const io = @import("std").io;

pub fn main() -> %void {
    %return io.stdout.printf("Hello, world!\n");
}

0.2.0 (март 2018):

const std = @import("std");

pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write("Hello, world!\n");
}

По сути этот синтаксис до сих пор остался. (и наверно работал бы на 0.14, если бы не ошибки-варнинги по типу variable is not mutable)

Про I/O и Writergate:

Don't Forget To Flush by Andrew Kelley

Осторожно, в начале громкий звук

Seems good for now but note this is going to disrupt my ultimate plan of creating a viable binary including when there are compilation errors. Including when there are syntax errors.

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

На моей памяти это первый раз, когда он упоминает этот план публично, я его ни в каких issues, PR и т.д. не видел раньше

https://github.com/ziglang/zig/pull/24857#issuecomment-3192324792

#upstream

Я спросил mlugg что это такое.

Если вкратце то уже сейчас ошибки по типу unused variable не предотвращают генерацию бинарника (его просто не отдают).
Так что идея расширить это для других видов ошибок. Бинарник будет выдаваться, но некоректные функции будут паниковать в рантайме. Это будет работать примено как ранее отвергнутый sloppy mode. Компилятор это и так уже делает для инкрементальной компиляции так что имеет смысл дать пользователю этим попользоваться

кстати интересные комментарии по поводу high-frequency trading в Zig:

https://www.reddit.com/r/Zig/comments/wqxrle/comment/il1tm7g/