/zig/lib/std/fmt.zig:662:22: error: values of type ‘[]const builtin.Type.StructField’ must be comptime-known, but index value is runtime-known
for (value, 0…) |elem, i| {
^~~~~
/zig/lib/std/builtin.zig:318:15: note: struct requires comptime because of this field
type: type,
^~~~
/zig/lib/std/builtin.zig:318:15: note: types are not available at runtime
type: type,
^~~~
/zig/lib/std/builtin.zig:321:20: note: struct requires comptime because of this field
alignment: comptime_int,
^~~~~~~~~~~~
is a tuple with a single field “.x” which is an enum literal.
You’re defining a struct here which has 1 indexed value which is of type .x. This doesn’t make much sense though, you’d probably mean to do something like:
With t I’m defining the struct and with y I’m using the struct I defined which is a single value anonymous struct whose value type is a variation of MyEnum. You’ll notice it’s indexable as well. You can also do something like this:
Many thanks for the clarifications. However, I’m still confused at some points.
What’s the principle difference between u8 and struct{x: u8,} in the following code. Aren’t they both two general types? We can’t get struct type info?
The error message for the second @typeInfo(t) does hint it is related to struct field, but the message is too hard for new zig programmers to understand.
There is a known issue with the compile time use of std.debug.print giving confusing messages:
If we walk through your original error message, we’ll see that it’s having an issue using the information you provided as it’s attempting to gather that info at runtime:
/zig/lib/std/fmt.zig:662:22: error: values of type ‘[]const builtin.Type.StructField’ must be comptime-known, but index value is runtime-known
for (value, 0…) |elem, i| {
^~~~~
This error is saying that it can’t iterate through the struct fields at compile time because because…
/zig/lib/std/builtin.zig:318:15: note: struct requires comptime because of this field
type: type,
^~~~
…one of the arguments (in the form of foo(comptime T: type)) is being evaluated at runtime.
This is because we’re calling the @TypeOf function on something that is already a type. The “type of” a “type” is just Builtin.Type.
Essentially, it looks like std.debug.print is having a hard time evaluating this at compile time. In the first case where you are printing a single u8, it looks like we can do that because we know what the offset is and it returns the correct thing. In a more generic case (a struct with a variable number of members) it’s struggling to return something about that in the runtime context.
This may be a bug (I submitted something regarding standard IO a while ago with the “zig test” feature because IO is tricky there as well). That github link I attached is evidence that this is causing some confusion and has been accepted because there is a pain-point here.
I think @zraineri covered everything else here. Looks like it’s just an issue with how we handle printing comptime stuff in the current version of Zig.
My confusions are still not totally cleared. Maybe I need some time to comprehend some zig corners eventually.
It is a sad fact that we can’t get type info of general struct types (It would be a good idea to mention the limit of @typeInfo and the @compileLog workaround in the doc of @typeInfo).