{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihvpuzbz43n5bbdbtp5e57k5jqpzt4jafhxsoypxs2ovhsffgmqvm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgawpedxngl2"
  },
  "path": "/t/pre-rfc-deprecation-and-separation-of-the-dead-code-lint/24045#post_15",
  "publishedAt": "2026-03-04T16:10:59.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "To me, the `dead_code` lint mostly does identify an interesting category, even if its name is odd. It’s the lint that tells you not just that you have superfluous things, but superfluous _things you purposefully designed as meaningful API_ — not just unused lines of code, but unused function signatures. Unused imports are not interesting because you delete them and then if you need them, you just put them back; and unreachable code is most likely a simple logic bug or work in progress; but `dead_code` tells you something more big-picture about your application.\n\nIt wouldn’t necessarily be a good idea to fold `unreachable_code` into `dead_code`, for example, because allowing `dead_code` is something one might do, for example, when developing and testing functions before they're exported or used publicly in any way; in this situation, `unreachable_code` is still helping you see logic bugs.\n\nAnother nuance of the situation is that `dead_code` acts transitively (it reports all items not reachable even if they are mentioned by other unreachable items, _and_ `allow`ing it allows all the dependencies of the item it’s allowed for), and if (as the OP proposed) it were broken up into `unused_functions` and `unused_compile_time_var`, since both of those things can use each other, it would be less clear how the transitivity should work.",
  "title": "Pre-RFC: Deprecation and separation of the dead_code lint"
}