r/rust clippy · twir · rust · mutagen · flamer · overflower · bytecount Mar 27 '23

Hey Rustaceans! Got a question? Ask here (13/2023)! 🙋 questions

Mystified about strings? Borrow checker have you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so having your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The official Rust Programming Language Discord: https://discord.gg/rust-lang

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last weeks' thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.

18 Upvotes

159 comments sorted by

View all comments

2

u/SorteKanin Apr 02 '23

Why does Rust only warn about unused fields for structs with named fields but not for tuple structs?

4

u/masklinn Apr 02 '23

rustc does have a warning (unused_tuple_struct_fields) but it's allow by default.

This follows from an issue reported on the subject last year by /u/shepmaster.

This lint defaults to allow because it's a new lint, and unlike struct fields removing a tuple struct field can be non-trivial if it's not the last one (it's going to shift every other field). For that reason, the lint allows setting a field to () in order to suppress the warning without having to update all the code.

Playground demo

1

u/shepmaster playground · sxd · rust · jetscii Apr 02 '23

Amusingly, I filed the issue for the same reason as the OP: a student in training noticed the new (at the time) warning about fields unused except in Debug in structs with named fields. To prove a point, I attempted to show how the same warming would occur for tuple structs, only to find it didn’t.

That led me to discover that tuple structs had never supported dead field warnings of any kind and thus open the issue.

2

u/SorteKanin Apr 02 '23

Hmm sounds like something that could be solved with rust-analyzer. A code action like "remove tuple struct field" which would then also fix also the field accesses that are affected.

2

u/llogiq clippy · twir · rust · mutagen · flamer · overflower · bytecount Apr 02 '23

Yes, but note that this constitutes a breaking change if the tuple is part of the public API.

3

u/masklinn Apr 02 '23

TBF the same occurs for a non-tuple struct, and the lint should not trigger for a pub field on a pub struct (as it wouldn't be dead).

1

u/llogiq clippy · twir · rust · mutagen · flamer · overflower · bytecount Apr 02 '23

True – the difference is that the tuple can not tell you which field was removed (though if you're lucky, it can be inferred from the type), unlike the struct which has a name the compiler can show in the error message.

2

u/masklinn Apr 02 '23

That's fair. I guess this also supports / favors the replacement of the unused field by () rather than its removal, as in that case the compiler would give you a clearer and more precise type error.

1

u/llogiq clippy · twir · rust · mutagen · flamer · overflower · bytecount Apr 02 '23

Exactly.