4 ms·

That makes unused variables "used", which defeats the point of the check.

vinay_ys 4y ago
Yep. Exactly. We want to be able to silence the compiler for a few iterations while the code is taking shape and then cleanup all the compiler lints in later iteration. In production CI pipeline, we can have all compiler lints on. This capability is very much needed to have a fast local dev iteration where compiler can assist but not impede.
- simlevesque 4y ago
  Eslint has `// eslint-disable-next-line no-unused-variables`, it is very useful. I'd prefer `eslint-expect-error-next-line` instead to warm me when the comment is actually useless but it's better than what Zig seem to do.
  - TakeBlaster16 4y ago
    There's a nice eslint plugin for disable-line hygiene: https://www.npmjs.com/package/eslint-plugin-eslint-comments https://www.npmjs.com/package/eslint-plugin-eslint-comments I do wish Rust had something like this too
    - steveklabnik 4y ago
      https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=be54d7e9501361d3f93d3dfe56252ef9 https://play.rust-lang.org/?version=stable&mode=debug&editio... You can put it at the top of your file with a #! too, if you want it to apply to the whole file.
      - TakeBlaster16 4y ago
        Oops I didn't explain clearly. Take this code: pub fn abc() -> usize { #[allow(deprecated)] "abc".len() } I want it to complain about the "allow", because there was never any deprecated warning emitted in the first place. Maybe it would be called #[expect(deprecated)] I refactor code all the time and find these stray "allow"s that aren't doing anything anymore
        steveklabnik 4y ago
        Ah, yeah that would be cool. Sorry for misunderstanding!
        voorwerpjes 4y ago
        This would be really cool! you should open up a RFC for it.
        eddyb 4y ago
        > Maybe it would be called #[expect(deprecated)] Both this and the reply saying you should open an RFC worry me that it was tongue-in-cheek. Or maybe it's the obvious name choice, heh, because it literally exists with that very syntax: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=73ff14fdc958b0f61796ccfa8d8eefbd https://play.rust-lang.org/?version=nightly&mode=debug&editi... Not stable yet, as you can see, but all the RFC and implementation work has been done, and a stabilization report was even put forward back in July: https://github.com/rust-lang/rust/issues/54503#issuecomment-1179563964 https://github.com/rust-lang/rust/issues/54503#issuecomment-...
        TakeBlaster16 4y ago
        That's hilarious, I had no idea! I'm glad I didn't embarrass myself by proposing an RFC. Thanks for the links!
    - simlevesque 4y ago
      Thank you !
- iainmerrick 4y ago
  But then what if you accidentally check in that workaround? The strict compiler check would have had exactly the opposite effect from the intended one.
  - deleted 4y ago
    [deleted]

Yep. Exactly. We want to be able to silence the compiler for a few iterations while the code is taking shape and then cleanup all the compiler lints in later iteration. In production CI pipeline, we can have all compiler lints on. This capability is very much needed to have a fast local dev iteration where compiler can assist but not impede.

simlevesque 4y ago
Eslint has `// eslint-disable-next-line no-unused-variables`, it is very useful. I'd prefer `eslint-expect-error-next-line` instead to warm me when the comment is actually useless but it's better than what Zig seem to do.
- TakeBlaster16 4y ago
  There's a nice eslint plugin for disable-line hygiene: https://www.npmjs.com/package/eslint-plugin-eslint-comments https://www.npmjs.com/package/eslint-plugin-eslint-comments I do wish Rust had something like this too
  - steveklabnik 4y ago
    https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=be54d7e9501361d3f93d3dfe56252ef9 https://play.rust-lang.org/?version=stable&mode=debug&editio... You can put it at the top of your file with a #! too, if you want it to apply to the whole file.
    - TakeBlaster16 4y ago
      Oops I didn't explain clearly. Take this code: pub fn abc() -> usize { #[allow(deprecated)] "abc".len() } I want it to complain about the "allow", because there was never any deprecated warning emitted in the first place. Maybe it would be called #[expect(deprecated)] I refactor code all the time and find these stray "allow"s that aren't doing anything anymore
      - steveklabnik 4y ago
        Ah, yeah that would be cool. Sorry for misunderstanding!
      - voorwerpjes 4y ago
        This would be really cool! you should open up a RFC for it.
      - eddyb 4y ago
        > Maybe it would be called #[expect(deprecated)] Both this and the reply saying you should open an RFC worry me that it was tongue-in-cheek. Or maybe it's the obvious name choice, heh, because it literally exists with that very syntax: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=73ff14fdc958b0f61796ccfa8d8eefbd https://play.rust-lang.org/?version=nightly&mode=debug&editi... Not stable yet, as you can see, but all the RFC and implementation work has been done, and a stabilization report was even put forward back in July: https://github.com/rust-lang/rust/issues/54503#issuecomment-1179563964 https://github.com/rust-lang/rust/issues/54503#issuecomment-...
        TakeBlaster16 4y ago
        That's hilarious, I had no idea! I'm glad I didn't embarrass myself by proposing an RFC. Thanks for the links!
  - simlevesque 4y ago
    Thank you !
iainmerrick 4y ago
But then what if you accidentally check in that workaround? The strict compiler check would have had exactly the opposite effect from the intended one.
- deleted 4y ago
  [deleted]