Congratulations and heartfelt thanks to the whole team! Yipee!
Awesome, great job everyone!
Release notes are fantastic, as always. This gave me a good chuckle:
Lo! Lest one learn a lone release lesson, let proclaim: “cancelation” should seriously only be spelt thusly (single “l”). Let not evil, godless liars lead afoul.
O, the sins of mispeling.
To simplify the language, it is no longer possible to reify tuple types with
comptimefields.
To simplify the language, it is no longer possible to reify error sets.
Would someone be able to explain what this means in practice (and also what the word “reify” means in this context)?
reify means making a concrete type from type information, which is what @Type used to do. This builtin is now split into, for example, @Tuple which, as you see, does not accept comptime fields. @Type, when it existed, was also able to reify error sets, but there’s no longer a way to do this.
Work to do to get things compiling again 
I like the packed union / struct changes.
The Io stuff is abracadabra to me still.
this changeset is expected to be generally easy for Zig programmers to manage, because it does not require much critical thinking.
Ouch! Why Zig programmers are singled out?
Lol, I didn’t mean it that way. Just that adding “io” argument is a lot easier than rewriting your Reader or Writer.
So, I guess Llamas will not be allowed?
You’ve taken it out of context. Most of the changes are simply adding the Io parameter, which requires zero critical thinking skills to execute.
Gosh, some people are so sensitive. 
var writer: std.Io.Reader = .fixed(buffer);
It is not that hard to guess the correct spelling though:
var writer: std.Io.Writer = .fixed(buffer);
Right: I should have spelled it `Requires Zero critical thinking skills."
I’m very excited to try this out and appreciate all of the work done in this release.
One thing to note: I see that we have many cool new changes have been added to the fuzzer, but running zig build test --fuzz after zig init seems to fail to compile from std changes on x86_64 linux:
Trying to run fuzzer
// using anyzig
$ zig 0.16.0 init
$ zig 0.16.0 build test --fuzz
info(web_server): web interface listening at http://[::1]:46785/
info(web_server): hint: pass '--webui=[::1]:46785' to use the same port next time
Build Summary: 5/5 steps succeeded; 3/3 tests passed
test
└─ run test
└─ compile test Debug native 1 errors
path/lib/compiler/test_runner.zig:566:55: error: expected type '*const debug.StackTrace', found '*builtin.StackTrace'
std.debug.writeStackTrace(trace, stderr) catch break :p;
^~~~~
path/lib/compiler/test_runner.zig:566:55: note: pointer type child 'builtin.StackTrace' cannot cast into pointer type child 'debug.StackTrace'
path/lib/std/builtin.zig:11:24: note: struct declared here
pub const StackTrace = struct {
^~~~~~
path/lib/std/debug.zig:604:24: note: struct declared here
pub const StackTrace = struct {
^~~~~~
path/lib/std/debug.zig:824:28: note: parameter type declared here
pub fn writeStackTrace(st: *const StackTrace, t: Io.Terminal) Writer.Error!void {
^~~~~~~~~~~~~~~~~
referenced by:
fuzz__anon_43958: path/lib/compiler/test_runner.zig:589:41
fuzz [inlined]: path/lib/std/testing.zig:1232:32
test.fuzz example: src/main.zig:43:25
error: 1 compilation errors
failed command: path/zig test -ffuzz -ODebug --dep foo -Mroot=path/src/main.zig -Mfoo=path/src/root.zig --cache-dir .zig-cache --global-cache-dir path/.cache/zig --name test --zig-lib-dir path/lib/ --listen=-
error: one or more unit tests failed to be rebuilt in fuzz mode
error: the following build command failed with exit code 1:
.zig-cache/o/d5998567d9a17182212e699ba1f271fa/build path/zig path/lib path .zig-cache path/.cache/zig --seed 0x619b697 -Za9e8ef37c309dad4 test --fuzz
It might be useful to set expectations for compile errors somewhere in the Fuzzer section.
Fyi, zig build test --fuzz -Doptimize=ReleaseSafe works.
There is already a PR for a fix https://codeberg.org/ziglang/zig/pulls/31863, and a plan of “if we care about it, there probably should be automated tests for it”. A note about the poorly timed breakage in the release notes isn’t a bad idea.
Sad that @cImport will disappear. It was one of the best features of Zig. A clear downgrade.
Let’s say, I need stdio.h in one Zig file while I need stdlib.h in another. How can I do this with the build system?
I think that in the second example for [ Environment Variables and Process Arguments Become Non-Global](0.16.0 Release Notes ⚡ The Zig Programming Language) the last line of
std.log.info("contains HOME: {any}", .{init.environ.contains(arena, "HOME")});
std.log.info("contains HOME (unempty): {any}", .{init.environ.containsUnempty(arena, "HOME")});
std.log.info("contains EDITOR: {any}", .{init.environ.containsConstant("EDITOR")});
std.log.info("contains EDITOR (unempty): {any}", .{init.environ.containsConstant("EDITOR")});
should read
std.log.info("contains EDITOR (unempty): {any}", .{init.environ.containsUnemptyConstant("EDITOR")});
but given previous responses on doc corrections/improvements, I am not sure I should file a PR for that.
I also really like @cImport in zig, it’s simple and convenient to use without requirement of build.zig and separate header files for translate-c module.
There’re many tiny single-file zig project, only one file.zig to compile and execute like script, which can import/use various c.h files efficiently. Just like cargo-script - a tool that lets you run single-file Rust scripts without creating a full Cargo project.
Zig already have this feature built-in, just zig run file.zig without dependencies. That’s so simple and fast, don’t need to create project folder with build.zig[.zon] files.
Many blog post promo Zig treat @cImport as a highlight feature of zig lang, now we’re going to remove it.
Can we preserve it as fallback way to import c header files, let developer choose which way to use cross-lang import items.
@cImport is being removed as it forces the language to depend on a c compiler to be feature complete. This is a necessary step towards ensuring zig does not need to depend on outside projects, which is important for focusing effort on developing and maintaining zig instead of e.g. fixing LLVM bugs.
The release notes show how you get equivalent behaviour with the build system directly under where it states @cImports removal.
In short there is a b.addTranslateC step, that has existed for a long time, and has long been the recommended approach when your import logic is less trivial.
zig is not a scripting language, so it is unreasonable to ask the zig team to keep a maintenance and development burden for an unintended usecase.
You can still use c libraries without the build system, you’d just need 2 extra files; a header with includes, and a file generated by zig translate-c that you then import.
That is what @cImport was an abstraction over, so there should be no loss of functionality.