a long time has passed since 0.16, I didn’t really find that many compilation errors upgrading from 0.16 (except ‘++’ and ‘**’)
it doesn’t have to be accurate, just what comes to mind
a long time has passed since 0.16, I didn’t really find that many compilation errors upgrading from 0.16 (except ‘++’ and ‘**’)
it doesn’t have to be accurate, just what comes to mind
For me the main ones in the migration were:
void can’t be initialized with .{} or void{}, use {}// Before
const Food = extern union {
breakdown: struct {...},
arr: [8]f32,
vec: @Vector(8, f32),
};
// To add a.vec = b.vec + c.vec;
// After
const Food = extern union {
breakdown: struct {...},
arr: [8]f32,
pub fn vec(self: @This()) @Vector(8, f32) {
return self.arr;
}
}
// To add a.arr = b.vec() + c.vec();
// My best friend has returned!
fn bitCast(T: type, value: anytype) T {
const N = @sizeOf(T);
if (@sizeOf(@TypeOf(value)) != N) @compileError("Bitcast must have equal sizes");
var ans: T = undefined;
const ansBytes: *[N]u8 = @ptrCast(&ans);
ansBytes.* = @as(*const [N]u8, @ptrCast(&value)).*;
return ans;
}
// Example
const S = extern struct{
a: f32,
b: f32,
};
// To convert to [2]f32:
// const C = bitCast([2]f32, myVariable);
The main thing I’m aware of this release cycle is that the make and the configure steps of zig build are now separate processes. Also the elements of the OptimizeMode enum were renamed, which mostly only affects you if you were writing mode == .Debug.
I’m not an expert, but: the configure step (which includes running your build.zig logic) is compiled in debug mode (so safety gains and also if you’re on x86_64, you benefit from the speed of the self-hosted backend), while the maker is compiled in ReleaseSafe (I think? which is also now just safe maybe?), so you get some speed gains, the configure and make steps being separated is good for the possibility of further sandboxing arbitrary (build) code execution down the line, and more of the compiler can be shipped as source code, which helps binary and tarball size (since typically that source code was coming your way anyway) and i’m told also makes tinkering on the compiler a bit easier.
The groundwork for the compiler server, api to interact for 3rd party tooling, which should make zls (and others) much better.
(you won’t see improvement in this release, currently it only provides parity with existing ways to get info)
someday, insha’Allah, hopefully, I will ask how zig.build is executed, for some reason I always postpone asking the question
oh, thanks. did not expect things related to extern to ever change (since the C ABI is old and stable), I think I should give actually learn about it
isn’t the evented io being implemented, and the translate-c is supposed to work with gtk on .17? but the team working on the backend makes me feel happy, maybe because it means it’s getting more and more stable (getting closer to its last shape)
anyways, thanks for your responses, I was afraid I was missing something or using some deprecated features without checking the docs
Neither evented Io nor the backends have anything to do with what I was talking about.
I mean the new API to interact with the compiler for tools like zls, won’t provide a noticeable improvement to zls in 0.17, but future releases will enable zls, and other tools, to do more.
Other features may be noticeably improved.
Devlog is a good preview:
I love reading those, but I did not want to bother you guys from the Zig team with this question.
though if you could allow me to ask a favor from you man, can you someday -only on your free time and if you feel like it- tell us why adding Canceled to Io.Reader is objectively wrong, because from what I understand from your talks, I believed it was already included. so now I do feel like I’m missing on some very important information. thanks, and sorry for the bother (I hate bothering people, not shy)
Let me turn the question around for you: why not add error.OutOfMemory to Io.Reader?