Skip to content
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

error on unused struct fields? #12854

Open
dee0xeed opened this issue Sep 15, 2022 · 12 comments
Open

error on unused struct fields? #12854

dee0xeed opened this issue Sep 15, 2022 · 12 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@dee0xeed
Copy link

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
Copy link
Contributor

leecannon commented Sep 15, 2022

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
Copy link
Contributor

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

@Vexu Vexu added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Sep 15, 2022
@Vexu Vexu added this to the 0.11.0 milestone Sep 15, 2022
@nektro
Copy link
Contributor

nektro commented Sep 15, 2022

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
Copy link
Author

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
Copy link
Contributor

nektro commented Sep 15, 2022

"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
Copy link
Author

"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
Copy link

ghost commented Sep 15, 2022

@dee0xeed
Copy link
Author

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
Copy link
Author

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

this issue is not about "changing the language"

@tauoverpi
Copy link
Sponsor Contributor

tauoverpi commented Sep 15, 2022

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
Copy link
Author

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
Copy link
Contributor

Jarred-Sumner commented Sep 16, 2022

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 andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Jul 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

8 participants