Skip to content

std.ArrayList(non-u8).Writer being a compileError hinders introspection #18350

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
michaelbartnett opened this issue Dec 22, 2023 · 2 comments
Closed
Labels
bug Observed behavior contradicts documented or intended behavior

Comments

@michaelbartnett
Copy link
Contributor

Zig Version

0.12.0-dev.1835+697b8f7d2

Steps to Reproduce and Observed Behavior

I'm writing some code that does some comptime introspection on types, but in order to check if a declaration is a type I want to recurse into, I need to use @TypeOf(@field(T, decl.name)), which triggers the compileError: "The Writer interface is only defined for ArrayList(u8)".

Here's a reduced example:

const std = @import("std");

pub fn listTypeDecls(comptime T: type) void {
    inline for (comptime std.meta.declarations(T)) |decl| {
        if (comptime @TypeOf(@field(T, decl.name)) == type) {
            std.log.info("{s}.{s} is a type", .{ @typeName(T), decl.name });
        }
    }
}

pub fn main() void {
    listTypeDecls(std.ArrayList(i32));
}

That produces this compiler output, which makes sense because @field is accessing the Writer declaration:

PS C:\Users\micha\dev\zigbug> zig build
zig build-exe zigbug Debug native: error: the following command failed with 1 compilation errors:
C:\standalone_programs\zigup\zig\0.12.0-dev.1835+697b8f7d2\files\zig.exe build-exe C:\Users\micha\dev\zigbug\src\main.zig --cache-dir C:\Users\micha\dev\zigbug\zig-cache --global-cache-dir C:\Users\micha\AppData\Local\zig --name zigbug --listen=-
Build Summary: 0/3 steps succeeded; 1 failed (disable with --summary none)
install transitive failure
└─ install zigbug transitive failure
   └─ zig build-exe zigbug Debug native 1 errors
C:\standalone_programs\zigup\zig\0.12.0-dev.1835+697b8f7d2\files\lib\std\array_list.zig:348:13: error: The Writer interface is only defined for ArrayList(u8) but the given type is ArrayList(i32)
            @compileError("The Writer interface is only defined for ArrayList(u8) " ++
            ^~~~~~~~~~~~~
referenced by:
    listTypeDecls__anon_2708: src\main.zig:6:30
    main: src\main.zig:19:18
    remaining reference traces hidden; use '-freference-trace' to see all reference traces

Checking for well-known types (e.g. if (comptime !std.mem.startsWith(@typeName(T), "array_list.ArrayList") and std.mem.eql(decl.name, "Writer")) {) doesn't prevent the error.

That listTypeDecls function resembles std.testing.refAllDecls, which also will not compile if you pass it std.ArrayList(non-u8) and try to run tests:

const std = @import("std");

test "refAllDecls error" {
    std.testing.refAllDecls(std.ArrayList(i32));
}

Expected Behavior

Barring some other overriding concern, if a standard library type is commonly used I expect to be able to iterate over its decls and check the type of those decls so I can introspect on nested types.

I also expect to still have a nice error when I try to call ArrayList(non-u8).writer(), but in a way that doesn't prevent looking at the decls of ArrayList (and other types using this idiom) at comptime.

@michaelbartnett michaelbartnett added the bug Observed behavior contradicts documented or intended behavior label Dec 22, 2023
michaelbartnett added a commit to michaelbartnett/zig that referenced this issue Dec 22, 2023
…o empty struct

When it's not valid for ArrayList or BoundedArray to expose a Writer interface:

- Keep the Writer declaration as a defined but empty type
- Move the compileError to the `writer()` function so people still get useful a error at the call site when trying to call e.g. `std.ArrayList(i32).writer()`
@ianprime0509
Copy link
Contributor

There's a proposal which would address this issue more generally: #6620

@michaelbartnett
Copy link
Contributor Author

Closing this then :) 6620 seems pretty critical, I wrote in the PR I opened for this that if 6620 doesn't happen then I think the stdlib should account for this issue.

Duplicates #6620

@michaelbartnett michaelbartnett closed this as not planned Won't fix, can't repro, duplicate, stale Jan 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants