Is it useful for std.enums.valuesFromFields and std.enums.values to return slices instead of pointers to arrays?

spiffyk · June 17, 2025, 7:36pm

Hi! Just a little discussion question about standard library functions.

I have been using the std.meta.tags function to iterate over enums—which works nicely, so I guess there is no need to change—BUT, I’ve only recently learned of the existence of std.enums.values and, consequently, std.enums.valuesFromFields.

At a first glance (while speaking strictly only about enums) std.meta.tags and std.enums.values do bascially the same thing – return all values of the enum, correctly typed. However, there is an important difference, that being that std.meta.tags returns a pointer to an array of enum values, while std.enums.values* return a slice of enum values. This might seem inconsequential, but there is an important difference – the former’s .len is of type comptime_int, while the latter’s .len is of type usize. This means the two functions are not drop-in interchangeable. In my codebase, swapping std.meta.tags for std.enums.values leads to compile errors, because I’m using the .len value for some calculations with u32 values, so I would need to add extra @intCasts.

Now, is there any advantage to the std.enums.values* functions having the slice return type? Since both lengths are always comptime-known, I would argue it would make sense for them to return array pointers, just like std.meta.tags already does. On that note, is there even a reason for std.enums.values to exist separately from std.meta.tags?

Justus2308 · June 17, 2025, 8:09pm

Hey, welcome to Ziggit!

The only difference between std.meta.tags() and std.enums.values() (besides their return type) seems to be that the former uses @enumFromInt() and the latter @field to populate the result.

Looking at the git blame that’s probably because of this:

But this isn’t relevant anymore because fields and decls cannot share names since 0.14.0:

github.com/ziglang/zig

Comment by mlugg - AstGen: disallow fields and decls from sharing names

master ← mlugg:field-decl-name-conflict

# Release Notes ## Fields and Declarations Cannot Share Names Zig 0.14.0 i…ntroduces a restriction that container types (`struct`, `union`, `enum` and `opaque`) cannot have fields and declarations (`const`/`var`/`fn`) with the same names. This restriction has been added to deal with the problem that whether `MyEnum.foo` looks up a declaration or an enum field is ambiguous (a problem amplified by \[Decl Literals\]\(TODO LINK TO RELEVANT RELEASE NOTES SECTION\)). Generally, this can be avoided by following the standard naming conventions: ```zig const Foo = struct { Thing: Thing, const Thing = struct { Data: u32, }; }; ``` --> ```zig const Foo = struct { thing: Thing, const Thing = struct { data: u32, }; }; ```

So I don’t think there is a reason for std.enums.values() to exist anymore.

I guess there is a case to be made for std.enums.valuesFromFields() though. Although the only usage of this function is inside std.enums:

github.com/ziglang/zig

lib/std/enums.zig

850655f06


      
                  pub fn keyForIndex(i: usize) E {
                      // TODO fix addition semantics.  This calculation
                      // gives up some safety to avoid artificially limiting
                      // the range of signed enum values to max_isize.
                      const enum_value = if (min < 0) @as(isize, @bitCast(i)) +% min else i + min;
                      return @as(E, @enumFromInt(@as(@typeInfo(E).@"enum".tag_type, @intCast(enum_value))));
                  }
              };
          }
          
          const keys = valuesFromFields(E, &fields);
          
          return struct {
              pub const Key = E;
              pub const count: comptime_int = fields_len;
              pub fn indexOf(e: E) usize {
                  for (keys, 0..) |k, i| {
                      if (k == e) return i;
                  }
                  unreachable;
              }

Also *const [n]T coerces to a slice anyway so it should always be preferred IMO.

spiffyk · June 17, 2025, 8:20pm

That definitely sounds useful. Though, if I’m not mistaken, the return type of that could easily be changed to *const [fields.len]E, no?

Justus2308 · June 17, 2025, 8:22pm

Yeah definitely, I think this would be a good change. Although I’m not really convinced whether std.enums.valuesFromFields() is very useful…

spiffyk · June 17, 2025, 9:04pm

I’m thinking something like iterating over the common values of an enum and its subset might be useful?

const A = enum { a, b, c, d };
const B = enum { b, d };

for (std.enums.valuesFromFields(A, std.meta.fields(B))) |a| {
    // ...
}

I don’t have a more concrete use-case right now, though.

Justus2308 · June 22, 2025, 2:56pm

I’ve opened an issue about this:

github.com/ziglang/zig

Remove std.enums.values[FromFields]

opened 02:50PM - 22 Jun 25 UTC

Justus2308

## Reasoning: `std.enums.values` does the exact same thing as `std.meta.tags`. …This used to be different back when decls and fields could have the same names and `@field` would prefer decls, in that case `std.enums.values` (which uses `@enumFromInt`) and `std.meta.tags` (which uses `@field`) could return different results (arguably a bug in `std.meta.tags`). But this is not possible anymore since [fields and decls cannot share names as of 0.14.0](https://ziglang.org/download/0.14.0/release-notes.html#Fields-and-Declarations-Cannot-Share-Names) making `std.enums.values` superfluous. `std.enums.values[FromFields]` is only used in one place in the entire codebase: in [`std.enums.EnumIndexer`](https://github.com/ziglang/zig/blob/75d0ec9c0476da61c6f32b3d386d8844faaeb1c5/lib/std/enums.zig#L1409). The argument for removing it from `std` isn't as strong but I still feel like it's too specific to belong there and also very confusing: ```zig const A = enum { a, b, c, d }; const B = enum { b, d }; const sect = std.enums.valuesFromFields(A, std.meta.fields(B)); ``` Fields of A: `{a,0} {b,1} {c,2} {d,3}` Fields of B: `{b,0} {d,1}` None of the fields match exactly, so what is `sect` here? a) `A{}` b) `A{ .b, .d }` c) `A{ .a, .b }` Answer c) is correct because `std.enums.valuesFromFields` chooses its returned values based on their integer values, but this is not obvious behaviour at all IMO. Especially since its name implies that it takes the entire field into consideration so I personally would expect a). Therefore I think both of these functions should be deprecated in the next release.

This probably doesn’t do what you think it does (see the issue)

spiffyk · June 22, 2025, 9:33pm

Oh, funny. The function’s doc comment is wrong then, because it says that the function only uses names and ignores values, but the actual code uses values instead of names.