error on unused struct fields?

[dee0xeed]

Currently Zig allows structs to have fields which are never used in a program, for example:

// usf.zig
const std = @import("std");
const print = std.debug.print;

const Object = struct {
    a: i32 = 1,
    b: i32 = 2,
};

pub fn main() void {
    const o = Object{};
    print("{}\n", .{o.a});
}

It would be nice if Zig could detect this and generate an error similar to the error about unused function arguments.
P.S. I always wanted to have such a feature in C.

[leecannon]

This won't work if the layout/contents of a struct are not under the control of the programmer.

For example when implementing a device driver you might need a struct like:

const SomeDeviceThing = extern struct {
    flags: u8,
    id: u8,
    enabled: u8,
};

If you only use flags and enabled a compile error for id being unused is unwanted, as its mere existence is "using" it as it affects the size/alignment of the struct and the offset of fields following it.

So some discard syntax will have to be provided that is analogous to _ = variable;

[marler8997]

@leecanon I was also thinking of that use case. What about non extern structs?

[nektro]

all fields are public so this feels like a non-starter. a field might not be being used by me, but it might be needed for someone else

[dee0xeed]

This won't work if the layout/contents of a struct are not under the control of the programmer.

I thought about "my own" structs, not extern.

If you only use flags and enabled a compile error for id being unused is unwanted

No doubt! But fields unused "by me" may be used outside of "my code" and if there is a field which is "globally" unused then it is not needed.

[nektro]

"my code" here refers to my entire program, not my library. if me and you are writing our own completely separate programs and you use all the fields of libFoo but I don't, I don't want program to not compile simply because I don't touch the entire api surface

[dee0xeed]

"my code" here refers to my entire program, not my library. if me and you are writing our own completely separate programs and you use all the fields of libFoo but I don't

but field unused by you is for sure used in the libFoo itself...

[ghost]

https://github.com/ziglang/zig/wiki/Language-Proposals

[dee0xeed]

If a struct is imported from "my project directory" it is definitely "my struct" and detecting unused fields won't hurt nobody.
If a struct is imported somewhere from <path-to-zig/lib> then of course there is no reason to detect fields unused "by me".

[dee0xeed]

https://github.com/ziglang/zig/wiki/Language-Proposals

this issue is not about "changing the language"

[tauoverpi]

Would work as long as the structs themselves are private and not extern/packed. pub structs can't fall under this rule but anything local to a file should be fine given they're not reachable outside anyway.

This is then similar to unused private functions.

[dee0xeed]

Would work as long as the structs themselves are private and not extern/packed. pub structs can't fall under this rule but anything local to a file should be fine given they're not reachable outside anyway.

I would extend this up to "anything local to a project", not just a file.

[Jarred-Sumner]

Alternate idea

When a non-packed, non-extern struct field has no usages with side effects (including no @bitCast, no @sizeOf, and no @bitSizeOf) on the parent struct (i.e. the size is not observable), automatically convert the type into a zero-bit type. Since the memory layout of non-packed, non-extern structs are not guaranteed, an optimization like this should be fine?

I imagine this would be particularly good for libraries. Features not in use would just not consume memory.

[andrewrk]

I would love to do this, but it is not possible since whether a field is used can depend on semantic analysis, which depends on conditional compilation, which means the compiler does not know whether a field is truly unused.

Related:

• "multibuilds" - a plan to harmonize conditional compilation with compile errors, documentation, and IDEs #3028
• compiler: remove unused struct fields #21010

[dee0xeed]

which means the compiler does not know whether a field is truly unused

ok, a man is the king in his house.
even if he "does not know whether a field is truly unused" :-)

so rubble detection should be implemented
in some external tool I guess.