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.

I do wish Rust had something like this too

You can put it at the top of your file with a #! too, if you want it to apply to the whole file.

  pub fn abc() -> usize {
      #[allow(deprecated)]
      "abc".len()
  }

I refactor code all the time and find these stray "allow"s that aren't doing anything anymore

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&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-...

The strict compiler check would have had exactly the opposite effect from the intended one.

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).

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

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.

Using `_ = var` to prevent the error is just as bad as handling Java exceptions with empty catch blocks.