Where 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.

I think rust calls them "zero sized types".

The ZSTs are unit types. They have one value, which we usually write as just the type name, so e.g.

    struct Goose;

    let x = Goose; // The variable x has type Goose, but also value Goose, the only value of that type

The choice to underscore that Rust's unit types have size zero is to contrast with languages like C or C++ where these types, which don't need representing, must nevertheless take up a whole byte of storage and it's just wasted.

But what we're talking about here are empty types. In Rust we'd write this:

    enum Donkey {}

    // We can't make any variables with the Donkey type, because there are no values of this type and a variable needs a value

No, 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.

Note 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.

I see. I can not give more insightful answer here then. From personal experience, I've noticed with 0.16 with the std.Io async stuff that you cannot do:

   io.concurrent(foo, .{});

where foo's return type is `error{foobar}!noreturn`, because the compiler crashes when it tries to use that type as a std.Io.Future(T)'s struct field. Might be related or not.

It is indeed (somewhat) related, and in fact that was fixed by this PR: https://github.com/ziglang/zig/issues/25771

Thanks 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.

Zog? What the hell man.

I 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.

> 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.

You're the man Kelley, don't let the doomers get to you