However, if you rename your enum fields, you’ll be able to use @tagName() to get an enum field name’s string, eliminating the need to store that info separately.
Your issue is in trying to access .TOKENS, which AFAIK is not possible like that. You need to access it on a value of type @This(), usually passed as an argument. This works for me (changed to use standard capitalization convention:
Not quite what I want. The values I store and use will not be the tag names.
This seems to be the best fit. The example is also clear. However the std.EnumArray is not clear for me. I will have to look for an example to check its aplicability.
Can you tell me what the advantage is of using these solutions? Please note I marked the other answer as a solution just because it answered my question “more directly”.
Can you explain why I need the self in the function. Any reason why I should not declare and use a const self = @Self() at the module level and use that? (seems to work) I guess my real question is, do we need to instantiate the structure, that is then discarded.
Why use a tag @"fn" instead of a simple fn? Is this a simple Zig idiom/convention?
I have just realized, don’t I have to allocate the string that I use in the array?
You can define tokens like var tokens: [@typeInfo(Token).@"enum".fields.len][:0]const u8 = undefined; instead, which will let you access it globally instead of as a field of @This().
Same reason you used @"if", that syntax lets you use keywords as values / variable names. fn is a keyword in zig. I just wanted to have multiple values in my test since I didn’t want the backing int of the enum to be u0. Though it probably doesn’t matter.