Hacker News Reader

Comment by Cloudef | Hacker News Reader

Pass by value / pass by ref is quite a bit of mental overhead as it effectively affects your ABI/API. Zig tries to not force this so as long as you "pass by value", the compiler can actually decide to pass it by reference. It does expose this kind of footgun though https://github.com/ziglang/zig/issues/5973#issuecomment-1330...

View on HN

Oof that's a very nasty bug. Is this still relevant in Zig or is there a workaround in the language? I'm not familiar with Zig, heard some good things about it, but this looks like a showstopper.

still relevant today, but as someone who writes a lot of Zig code I haven't ever really encountered it in the wild. You definitely could, though, and it'd be wildly confusing.

Luckily, the Zig core team has recognized it is an issue and plan to address it before 1.0 :)

It's rare to hit it, but if you do, having it happen silently is not ideal for sure.

I still think noalias-by-default is the way to fix this.

https://github.com/ziglang/zig/issues/1108

You get all the benefits of Zig being able to choose the function ABI, but if the optimization would have caused a bug, you'll get an immediate panic at the function entrypoint, instead of silently corrupted data.

It’s a bit confusing when compared with other programming languages. But the Zig docs’ introduction to structs are pretty clear that they can be pass-by-value or pass-by-reference at the compiler’s discretion. If you need a copy, make a copy; if you need a reference, pass a pointer; if you don’t care, the compiler will pick one.

The issue is still Open.

I think this is the same in the still experimental Carbon

There is also a another paradigm where parameters are marked as in, out or inout parameters as in D (?) and cpp2 which makes the intent clear

> I think this is the same in the still experimental Carbon

Apparently, it's not (anymore?):

https://github.com/ziglang/zig/issues/5973#issuecomment-1801...

Reply on news.ycombinator.com