> It has comptime types and it also has a TypeInfo built-in with some degree of reflection? Is that runtime reflection maybe? I do wish this was explained more

> It has comptime types and it also has a TypeInfo built-in with some degree of reflection? Is that runtime reflection maybe? I do wish this was explained more prominently! The way this seems to work is that Zig has a lazy runtime for Zig code at compile time that does some interning (such that identical types obtained separately are equal, identical strings obtained separately are equal, etc.), and some types such as type can only exist in this runtime, not in the actual uh "run time" runtime. TypeInfo is for iterating over struct, union, or enum definitions at compile time to generate code. You'd use it if you wanted to write a generic json parser and serializer or if you wanted to write a type that's like an arraylist but internally uses a struct-of-arrays layout. Both of these are in the standard library and make informative reading. TypeInfo itself is a union that can exist at runtime, but I don't think you can get into a situation where you have something at runtime and you don't know what type it is already. So actually using the TypeInfo at runtime may not be very useful. > Zig appears to not report compiler errors for functions that get optimized out. This is apparently caused by the laziness. The docs suggest using std.testing.refAllDecls(@This()) to have the compiler check unreachable code. I mean the actual usable docs at https://ziglang.org/documentation/master/#Nested-Container-Tests https://ziglang.org/documentation/master/#Nested-Container-T... rather than the automatically generated stdlib docs.