4 ms·

You can always do ' _ = your_varible', don't have to comment individuals

avgcorrection 4y ago
That was the first suggestion that Kelley posted on the issue and judging by the reactions people weren’t happy with it.
- masklinn 4y ago
  Completely unsurprisingly. "Add useless garbage to work around the stupid decisions we impose on you" is not very appreciated.
  - flumpcakes 4y ago
    It is not useless though. There is a big difference between an unused variable and explicitly defining an unused variable. Kelly is designing Zig to do nothing surprising or change things underneath you. Even C does things that are surprising. If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable).
    - masklinn 4y ago
      > It is not useless though. True, it's actively harmful. > There is a big difference between an unused variable and explicitly defining an unused variable. Which is not helpful when you're only doing it to hide a compiler error foisted upon you. > Kelly is designing Zig to do nothing surprising or change things underneath you. Refusing to compile my code because I've an unused variable is certainly surprising. > If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. That is the opposite of making sense. If you are actively forcing the use of a variable then the compiler removing it anyway is exactly surprising. > I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable). 1. that it's an error is the entire problem here 2. and as far as I'm concerned it's a ridiculously weak warning, if your standard is that no action should be useless you need an unused store error, which subsume unused variables
      - flumpcakes 4y ago
        > That is the opposite of making sense. If you are actively forcing the use of a variable then the compiler removing it anyway is exactly surprising. I disagree, you are actively telling the compiler that this is dead code.
        masklinn 4y ago
        > I disagree, you are actively telling the compiler that this is dead code. No, you would be doing that by removing the code. You are telling the compiler that this is code you want and to shut the fuck up.
    - alpaca128 4y ago
      This method is more a hack to confuse the compiler than a clean solution, and now this unused variable could stay in the code forever because the compiler won't ever mention it again. Using `_ = var` to prevent the error is just as bad as handling Java exceptions with empty catch blocks.
- TakeBlaster16 4y ago
  His suggestion is even counterproductive in a way, because it makes it more likely people will accidentally commit unused vars they have silenced. I _want_ the compiler to help me find unused things... just not yet. Wait until my pre-commit hook to yell at me please!
  - anonymoushn 4y ago
    I've definitely done this, and this is a good argument for changing the behavior.
dmytrish 4y ago
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

That was the first suggestion that Kelley posted on the issue and judging by the reactions people weren’t happy with it.

masklinn 4y ago
Completely unsurprisingly. "Add useless garbage to work around the stupid decisions we impose on you" is not very appreciated.
- flumpcakes 4y ago
  It is not useless though. There is a big difference between an unused variable and explicitly defining an unused variable. Kelly is designing Zig to do nothing surprising or change things underneath you. Even C does things that are surprising. If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable).
  - masklinn 4y ago
    > It is not useless though. True, it's actively harmful. > There is a big difference between an unused variable and explicitly defining an unused variable. Which is not helpful when you're only doing it to hide a compiler error foisted upon you. > Kelly is designing Zig to do nothing surprising or change things underneath you. Refusing to compile my code because I've an unused variable is certainly surprising. > If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable. That is the opposite of making sense. If you are actively forcing the use of a variable then the compiler removing it anyway is exactly surprising. > I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable). 1. that it's an error is the entire problem here 2. and as far as I'm concerned it's a ridiculously weak warning, if your standard is that no action should be useless you need an unused store error, which subsume unused variables
    - flumpcakes 4y ago
      > That is the opposite of making sense. If you are actively forcing the use of a variable then the compiler removing it anyway is exactly surprising. I disagree, you are actively telling the compiler that this is dead code.
      - masklinn 4y ago
        > I disagree, you are actively telling the compiler that this is dead code. No, you would be doing that by removing the code. You are telling the compiler that this is code you want and to shut the fuck up.
  - alpaca128 4y ago
    This method is more a hack to confuse the compiler than a clean solution, and now this unused variable could stay in the code forever because the compiler won't ever mention it again. Using `_ = var` to prevent the error is just as bad as handling Java exceptions with empty catch blocks.
TakeBlaster16 4y ago
His suggestion is even counterproductive in a way, because it makes it more likely people will accidentally commit unused vars they have silenced. I _want_ the compiler to help me find unused things... just not yet. Wait until my pre-commit hook to yell at me please!
- anonymoushn 4y ago
  I've definitely done this, and this is a good argument for changing the behavior.

dmytrish 4y ago

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