4 ms·

Does Zig still have that insane compiler enforced no unused variables policy? Honestly, that is such a stupid thing that it literally kept me away from the lang

by kaba0 4y ago

Does Zig still have that insane compiler enforced no unused variables policy? Honestly, that is such a stupid thing that it literally kept me away from the language, which I otherwise find interesting for its niche.

mekoka 4y ago
I'm waiting for the first fork that will do away with that "feature".
- markisus 4y ago
  It already exists. You’ll just have to compile it yourself which is relatively easy. https://github.com/markisus/unzig https://github.com/markisus/unzig
flohofwoe 4y ago
The feature is really quite ok when working in an IDE where those errors are displayed immediately as error squiggles, and there's now also an error for any 'left-over' _ = unused_variable; ...statements (although I'm starting to prefer Typescript's convention to mark unused variables and function parameters with a leading underscore to suppress unused errors). In any case, once I started to write more TS code where the TS compiler and linters are usually configured to also catch any unused variables as "errors" I no longer see Zig's stance on the same thing as critical as before, it's more or less "just" a tooling issue.
- kaba0 4y ago
  But why should I have to recursively modify my code when I am experimenting with shit? Like, am I the one that does something wrong, because commenting/uncommenting a single line to check the outcome of a program is extremely common in my workflow, and that fkin compile error can absolutely throw me out of the loop of what I was trying to do. And it is not even hard to solve, just add a “production” profile where it is an error for all I care, and a “debug” one where it really shouldn’t be linting my code unnecessarily.
  - flohofwoe 4y ago
    To be clear, I would also actually prefer if those were warnings in development mode, but so far at least Zig has no warnings, only errors. But I'm open to the idea that the Zig team knows what they are doing ;)
    - tialaramex 4y ago
      AIUI Zig has embraced the view that either something is bad, and so it's an error and we shouldn't compile, or it's fine so no need for a warning. I don't think this actually is a reasonable stance although I can see why C might make you think so. Rust's linter, clippy, provides a rich seam of stuff that definitely shouldn't be fatal but some / many people would value knowing about. For example yesterday I built a Range which intentionally is the wrong way up, isize::MAX..isize::MIN - and so clippy says well, that's probably not what you wanted. This is a good lint. If I ever do the same thing by mistake I definitely want to know about it, but this time was not a mistake, so I wrote an allow attribute on that Range to silence the linter and also flag to readers, "No, this is on purpose".
Gigachad 4y ago
Really seems like something that should be a lint rule..
- deleted 4y ago
  [deleted]
tialaramex 4y ago
Product of the creator's will. Andrew is confident that always rejecting programs with unused variables catches bugs, and he believes that if you don't like this you should have software to adapt the Zig you write so that it compiles, by adding or removing _ = unused_variable; style statements to consume the otherwise unused variables. There can be a benefit to a singular coherent vision behind something - committees can produce languages which don't do anything well by compromising everywhere - but one of the negatives of visionaries is that they can stubbornly stick to their preferences overriding any other consideration. Andrew is quite sure he's right, nothing will overcome that. It's OK, C++ manages to suffer from afflictions of a single coherent vision (Bjarne Stroustrup's) and having an unwieldy committee structure (WG21 the "C++ Standards Committee") and despite the resulting flaws it was enormously successful.
- banyaaa 4y ago
  What's an example of a bug that would be caused by having an unused variable? I honestly can't think of one.
  - eska 4y ago
    Store an error code forget to check it, store a future but fail to poll it, etc.
    - kaba0 4y ago
      Which is absolutely not solved by assigning it to _ neither, if anything it will just make the variable appear used in syntax highlighting and that will make me forget to properly use it! IDEs just gray out the unused variables and that is an 1000x better way of handling this issue.
      - eska 4y ago
        I think you misunderstand the purpose of assigning to _. Extremely common bug 1: a function returns an error/future, but you don’t check/poll it “foo();”. May happen because you copy some tutorial code that’s not rigid about error checking, or you don’t realize that this language doesn’t have futures that run without being polled. Quite common bug 2: you store the error/future, but don’t check/poll it “let a = foo();”. May happen when moving code, certain branches, copy paste error, not enough coffee. Opt-in: it doesn’t matter if the call succeeded or the future is polled, leave me alone “let _ = foo()”. May happen in test code for example. This is not the common case, so the opt-in annoyance is justified to improve the common case.
HeavyFeather 4y ago
“Insane” really? How so? In what world do unused variables make sense?
infamouscow 4y ago
I think forgetting to assign a variable to the return value and ignoring the return value are two different things. Zig regards forgetting to assign a variable to a return value as a compile time error because there's an entire class of bugs that stem from it, e.g. resource leaks.

by kaba0 4y ago

mekoka 4y ago

I'm waiting for the first fork that will do away with that "feature".

markisus 4y ago
It already exists. You’ll just have to compile it yourself which is relatively easy. https://github.com/markisus/unzig https://github.com/markisus/unzig

flohofwoe 4y ago

The feature is really quite ok when working in an IDE where those errors are displayed immediately as error squiggles, and there's now also an error for any 'left-over' _ = unused_variable; ...statements (although I'm starting to prefer Typescript's convention to mark unused variables and function parameters with a leading underscore to suppress unused errors). In any case, once I started to write more TS code where the TS compiler and linters are usually configured to also catch any unused variables as "errors" I no longer see Zig's stance on the same thing as critical as before, it's more or less "just" a tooling issue.

kaba0 4y ago
But why should I have to recursively modify my code when I am experimenting with shit? Like, am I the one that does something wrong, because commenting/uncommenting a single line to check the outcome of a program is extremely common in my workflow, and that fkin compile error can absolutely throw me out of the loop of what I was trying to do. And it is not even hard to solve, just add a “production” profile where it is an error for all I care, and a “debug” one where it really shouldn’t be linting my code unnecessarily.
- flohofwoe 4y ago
  To be clear, I would also actually prefer if those were warnings in development mode, but so far at least Zig has no warnings, only errors. But I'm open to the idea that the Zig team knows what they are doing ;)
  - tialaramex 4y ago
    AIUI Zig has embraced the view that either something is bad, and so it's an error and we shouldn't compile, or it's fine so no need for a warning. I don't think this actually is a reasonable stance although I can see why C might make you think so. Rust's linter, clippy, provides a rich seam of stuff that definitely shouldn't be fatal but some / many people would value knowing about. For example yesterday I built a Range which intentionally is the wrong way up, isize::MAX..isize::MIN - and so clippy says well, that's probably not what you wanted. This is a good lint. If I ever do the same thing by mistake I definitely want to know about it, but this time was not a mistake, so I wrote an allow attribute on that Range to silence the linter and also flag to readers, "No, this is on purpose".

Gigachad 4y ago

Really seems like something that should be a lint rule..

deleted 4y ago
[deleted]

tialaramex 4y ago

Product of the creator's will. Andrew is confident that always rejecting programs with unused variables catches bugs, and he believes that if you don't like this you should have software to adapt the Zig you write so that it compiles, by adding or removing _ = unused_variable; style statements to consume the otherwise unused variables. There can be a benefit to a singular coherent vision behind something - committees can produce languages which don't do anything well by compromising everywhere - but one of the negatives of visionaries is that they can stubbornly stick to their preferences overriding any other consideration. Andrew is quite sure he's right, nothing will overcome that. It's OK, C++ manages to suffer from afflictions of a single coherent vision (Bjarne Stroustrup's) and having an unwieldy committee structure (WG21 the "C++ Standards Committee") and despite the resulting flaws it was enormously successful.

banyaaa 4y ago
What's an example of a bug that would be caused by having an unused variable? I honestly can't think of one.
- eska 4y ago
  Store an error code forget to check it, store a future but fail to poll it, etc.
  - kaba0 4y ago
    Which is absolutely not solved by assigning it to _ neither, if anything it will just make the variable appear used in syntax highlighting and that will make me forget to properly use it! IDEs just gray out the unused variables and that is an 1000x better way of handling this issue.
    - eska 4y ago
      I think you misunderstand the purpose of assigning to _. Extremely common bug 1: a function returns an error/future, but you don’t check/poll it “foo();”. May happen because you copy some tutorial code that’s not rigid about error checking, or you don’t realize that this language doesn’t have futures that run without being polled. Quite common bug 2: you store the error/future, but don’t check/poll it “let a = foo();”. May happen when moving code, certain branches, copy paste error, not enough coffee. Opt-in: it doesn’t matter if the call succeeded or the future is polled, leave me alone “let _ = foo()”. May happen in test code for example. This is not the common case, so the opt-in annoyance is justified to improve the common case.

HeavyFeather 4y ago

“Insane” really? How so? In what world do unused variables make sense?

infamouscow 4y ago

I think forgetting to assign a variable to the return value and ignoring the return value are two different things. Zig regards forgetting to assign a variable to a return value as a compile time error because there's an entire class of bugs that stem from it, e.g. resource leaks.