6 ms·
Originally, Zig's type system was less disciplined in terms of the "zero" type (also known as "noreturn"). This was proposed, discussed, and accepted here: htt
by AndyKelley 6mo ago
Originally, Zig's type system was less disciplined in terms of the "zero" type (also known as "noreturn").
This was proposed, discussed, and accepted here: https://github.com/ziglang/zig/issues/3257 https://github.com/ziglang/zig/issues/3257
Later, Matthew Lugg made a follow-up proposal, which was discussed both publicly and in ZSF core team meetings. https://github.com/ziglang/zig/issues/15909 https://github.com/ziglang/zig/issues/15909
He writes:
> A (fairly uncontroversial) subset of this behavior was implemented in [the changeset we are discussing]. I'll close this for now, though I'll probably end up revisiting these semantics more precisely at some point, in which case I'll open a new issue on Codeberg.
I don't know how evident this is to the casual HN reader, but to me this changeset very obviously moves Zig the language from experimental territory a large degree towards being formally specified, because it makes type resolution a Directed Acyclic Graph. Just look at how many bugs it resolved to get a feel for it. This changeset alone will make the next release of the compiler significantly more robust.
Now, I like talking about its design and development, but all that being said, Zig project does not aim for full transparency. It says right there in the README:
> Zig is Free and Open Source Software. We welcome bug reports and patches from everyone. However, keep in mind that Zig governance is BDFN (Benevolent Dictator For Now) which means that Andrew Kelley has final say on the design and implementation of everything.
It's up to you to decide whether the language and project are in trustworthy hands. I can tell you this much: we (the dev team) have a strong vision and we care deeply about the project, both to fulfill our own dreams as well as those of our esteemed users whom we serve[1]. Furthermore, as a 501(c)(3) non-profit we have no motive to enshittify.
[1]: https://ziglang.org/documentation/master/#Zen https://ziglang.org/documentation/master/#Zen
It's been incredible working with Matthew. I hope I can have the pleasure to continue to call him my colleague for many years to come.
- hitekker 6mo ago> Zig the language from experimental territory a large degree towards being formally specified Great to hear; I look forward to reading the language spec one day.
- norman784 6mo agoI don't use Zig (is not a language for me), but I like to read/watch about it, when you or others talk about the language design and the reasons behind the changes. Thanks for your and the Zig team work.
- tialaramex 6mo agoWhere does the name "zero type" come from? In type theory this is called an "empty" type because the set of values of this type is empty and I couldn't find (though I have no idea where to start) mention of it as a "zero" type. This stuff is foundational and so it's certainly a priority to get it right (which C++ didn't and will be paying for until it finally collapses under its own weight) but it's easier to follow as an outsider when people use conventional terminology.
- Cloudef 6mo agoI think rust calls them "zero sized types".
- mk12 6mo agoNo, that’s a different thing. “noreturn” is like Rust’s “never” type (spelled as an exclamation mark, !). Also known as an “uninhabited type” in programming language theory.
- tialaramex 6mo agoNote that Rust's ! isn't stabilized, however you can (in stable Rust, today) make your own empty/ uninhabited types, yours just isn't "the" canonical empty type for the language, and so the type arithmetic won't necessarily see that it's the same thing in some cases if that matters. Rust's core::convert::Infallible is such a type, representing in that case the error type for conversions which have no errors. For example, we can try to convert most numeric types into a 16-bit unsigned type, and obviously most of them can fail because your value was too big or negative or whatever. u16 however obviously never fails, the conversion is a no-op, nevertheless it would be stupid if we can't write generic code to convert it - so of course we can, and if we wrote generic error handling code, that code is dead for the u16 case, we can't fail, the use of empty types here justifies the compiler saying OK, that code is dead, don't emit it. Likewise converting u8 to u16 can't fail - although it's slightly more than a no-op in some sense - and so again the error handling is dead code.
- Cloudef 6mo ago
- throwaway17_17 6mo agoThanks for the reply Andrew, I certainly did not mean to imply any issues with trustworthiness for Zig users or prospective adopters. Also, I absolutely did not intend to imply any negatives toward Zog’s evolution or this particular development on the compiler’s internals. I enjoy all of the process and implementation content, i.e. videos, podcast, and blogs that yourself and contributors have provided through various platforms over the years. I made a comment from a relatively u informed place and it seems to have been taken as a negative remark on Zig or the language and compiler’s development. Apologies if it was seen that way yourself or other contributors. As for Matthew, the work both planning and implementing these changes was clearly a large undertaking and I certainly applaud that and hope no one thought otherwise.
- bro45x 6mo agoZog? What the hell man.
- bro45x 6mo agoYou're the man Kelley, don't let the doomers get to you