3 ms·

const connection = try http_server.accept(); defer connection.stream.close(); This pattern of reaching into the returned struct's internals is so weird to me

const connection = try http_server.accept(); defer connection.stream.close(); This pattern of reaching into the returned struct's internals is so weird to me. Why not just connection.close()? Unnecessary Use of var Sounds like yet another case of "this should be a warning instead".

ginko 3y ago
> Sounds like yet another case of "this should be a warning instead". Agreed. There should at least be a way to turn this into a warning during development.
- flohofwoe 3y ago
  If it takes the same direction as the controversial "unused vars are errors" feature, IDE integrations will take care of that. For instance in VSCode the unused-var-error has become a complete non-issue taken care of by autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. 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.
  - masklinn 3y ago
    > IDE integrations will take care of that 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.
    - flohofwoe 3y ago
      > So this is an IDE-mandatory language which does not come with an IDE? 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).
      - masklinn 3y ago
        > Nope. 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.
        AndyKelley 2y ago
        > It's completely useless It seems like you're forgetting that it shows up in diffs (code reviews) and text editors.
  - throwawaymaths 3y ago
    > For instance in VSCode the unused-var-error has become a complete non-issue taken care of by autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. this doesn't help anyone writing autogen code, though.
HeavyStorm 3y ago
A violation of the Law of Demeter.
wild_pointer 3y ago
> Sounds like yet another case of "this should be a warning instead". The discussion about it is indeed interesting: https://github.com/ziglang/zig/issues/224 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.
NoReligion 3y ago
[dead]

ginko 3y ago

> Sounds like yet another case of "this should be a warning instead". Agreed. There should at least be a way to turn this into a warning during development.

flohofwoe 3y ago
If it takes the same direction as the controversial "unused vars are errors" feature, IDE integrations will take care of that. For instance in VSCode the unused-var-error has become a complete non-issue taken care of by autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. 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.
- masklinn 3y ago
  > IDE integrations will take care of that 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.
  - flohofwoe 3y ago
    > So this is an IDE-mandatory language which does not come with an IDE? 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).
    - masklinn 3y ago
      > Nope. 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.
      - AndyKelley 2y ago
        > It's completely useless It seems like you're forgetting that it shows up in diffs (code reviews) and text editors.
- throwawaymaths 3y ago
  > For instance in VSCode the unused-var-error has become a complete non-issue taken care of by autoformatting through the Zig language server by inserting or removing '_ = unused_var;' as needed. this doesn't help anyone writing autogen code, though.

HeavyStorm 3y ago

A violation of the Law of Demeter.

wild_pointer 3y ago

> Sounds like yet another case of "this should be a warning instead". The discussion about it is indeed interesting: https://github.com/ziglang/zig/issues/224 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.

NoReligion 3y ago

[dead]