> as name of the type, I think I like void more than ()
It's the wrong name though. In type theory, (), the type with one member, is traditionally called "Unit", while "Void" is the uninhabited type. Void is the return type of e.g. abort.
It fulfills the same role as C and C++'s void type. I don't think most systems programmers care about type theorist bikeshedding about purity with formal theory.
A ton of people coming to Zig are going to be coming from C and C++. void is fine.
If I understood `abort` semantics correctly, it has a type of `never` or Rust's `!`. Which has a meaning "unobtainable value because control flow went somwhere else". `void` is closer to `unit` or `()` because it's the type with no allowed values.
Cool trick: some languages (e.g. TypeScript) allow `void` generics making parameters of that type optional.
There's a huge semantic difference: a type with zero allowed values can never be constructed.
This means that a function that returns an uninhabited type is statically known to not return -- since there's no way it could construct an uninhabited value for a return expression. It also means you can coerce a value of uninhabited type into any other type, because any code which recieves a value of an uninhabited type must be unreachable.
For instance, in Rust you can write the following:
Because panic! aborts the program and doesn't return, its return type is uninhabited. Thus, a panic! can be used in a context where a string is expected.
We were talking about `void`, not `!`. It's clear that "never" type has a special language support. Difference between `void` and `()` is much less subtle.
It's the wrong name though. In type theory, (), the type with one member, is traditionally called "Unit", while "Void" is the uninhabited type. Void is the return type of e.g. abort.