{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicxr2dzqotnmoei7te5yiyxb4xdxifdwr2ut6g5upk6nlsgm62y5m",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgsq6xidkuf2"
  },
  "path": "/t/pre-feature-request-suppress-unused-variable-warning-for-unit-type-arguments/24065#post_10",
  "publishedAt": "2026-03-11T16:30:14.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "RalfJung:\n\n> I don't see noise here.\n\nWarnings should be precise is a general statement about warnings. If the compiler can be taught a special case for a warning that eliminates a whole class of false positives then (other factors aside) it should be taught that special case. Ideally when I see a warning I am expecting an issue with my code, not expecting to `allow` it.\n\nThe case in the OP _is noise_ : the warning needs to be `allow`'d or otherwise disabled. I don't think there is an easy way for the compiler to be taught that some ZST's are tokens and some are ignorable. Perhaps an annotation on the struct, but then I wonder: if the code were then changed to add a parameter to that empty struct, I would probably remove the annotation and trigger the warning everywhere (and then either use my new parameter or silence it with `let _ =`). So having N places where the warning is disabled (via prefix `_`) doesn't seem that big a deal.",
  "title": "Pre-feature request: suppress unused variable warning for unit-type arguments"
}