const connection = try http_server.accept();
defer connection.stream.close();
Unnecessary Use of var
The discussion about it is indeed interesting: https://github.com/ziglang/zig/issues/224
e.g.:
> > When debugging/prototyping, it's useful to comment out a line without having to refactor, e.g. > > I think this use case is a strong argument. However, it's up against another strong use case, which is the ability to rely on a set of assumptions when reading the source of a compiling codebase. > [...] > a variable declared with var does have a modification to it
Which is an interesting property.
We'll see how it goes for them.
Agreed. There should at least be a way to turn this into a warning during development.
But TBH, I'm using similar strict error settings in TS/ESLint for a long time now (as part of our company linter rules) without autoformatting and it's fine.
So this is an IDE-mandatory language which does not come with an IDE?
> autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed.
So the error has become a non issue by completely undermining it? That seems like the opposite of a good idea.
> I'm using similar strict error settings in TS/ESLint
A linter or an IDE "error" is equivalent to a compiler warning: they don't prevent compiling and running the code.
And JS/TS's const is much weaker than Zig's, essentially trivial: zig's const means the value is immutable, not just the binding.
Nope. AFAIK the autofixing is actually implemented by `zig fmt`. The IDE integration just makes that feature available as "VSCode Formatter".
> So the error has become a non issue by completely undermining it? That seems like the opposite of a good idea.
Nope. The important part is that the autofix works in both directions. E.g. if an unused-fix was added before, it will be removed as soon as the variable is used. This makes the development workflow painless, but at the same time the code cannot become littered with redundant unused-fixes. It's also trivial to search for the "_ =" discard pattern to find any leftover discards (in a 'final' codebase there shouldn't be any of those).
> A linter or an IDE "error" is equivalent to a compiler warning: they don't prevent compiling and running the code.
Nope, in our case it's an actual hard compile error. You can't "npm build" or even git-commit a project that has unused variables (which are not explicitly discarded).
Except yes, and your clarifications confirm it. If the formatter automatically adds and removes artificial uses for unused variables then you're undermining the diagnostic since you're automatically suppressing it. It's completely useless. Worse than useless even.
Not to mention zig's diagnostic is as crap as go's: it doesn't track unused stores, so it only catches a minuscule number of possible issues, and misses the much larger one, yielding both incredible annoyance and false confidence, all because the maintainers of both languages refuse to support warnings.
> It's also trivial to search for the "_ =" discard pattern to find any leftover discards (in a 'final' codebase there shouldn't be any of those).
Meanwhile a warning actually tells you directly and reminds you, without having to "search for the discard pattern".
> Nope, in our case it's an actual hard compile error.
Boy am I happy not to work with you.
It seems like you're forgetting that it shows up in diffs (code reviews) and text editors.
So it’s worse than useless, it’s actively harmful.
It wasn't my decision to introduce such draconic rules, but in practice it turned out to be a non-issue. Production code should be warning-free, and warnings should be treated as errors. Two simple rules that both make a lot of sense, no matter what language.
PS: that 'unused variables are errors' linter rule is actually coming from the airbnb eslint plugin (which AFAIK is quite popular in the JS/TS world: https://github.com/airbnb/javascript/blob/c25bce83be4db06e6a...)
this doesn't help anyone writing autogen code, though.