The thing I am worried about is not somebody having an option to disable guardrails while playing in his/her sandbox, but that this option is going to be (ab)used “in production environment”. E.g. “we need this feature last week, no time to refactor, we’ll do it later”, etc.
And no, administrative measures (“don’t use --sloppy”!) don’t always work.
1 Like
Isn’t that way of abuse already there with --autofix?
Honestly I think autofix is even worse than sloppy in that regard, since at least with sloppy we can get the errors back by removing the flag later.
Also “don’t use --sloppy in production” can be enforced by the project manager with CI, while --autofix usage cannot even be detected reliably.
3 Likes
In early days of Rust (before 1.0 release) there was lot of pressure to make borrow-checker optionally replace errors with warnings. But Rust team resisted and now memory safety guaranteed by borrow-checker is the Rust’s main selling point. Unconditionally barring sloppy code from compiling is a feature not a bug.
2 Likes
I’m unfamiliar with --autofix. What is it?
It can be enforced but it doesn’t necessarily have to be. Like I said, there are circumstances when you will be tempted (or outright pushed by the management) to skip the checks and just ship the next release already.
It automatically inserts _ = and other fixes to compiler errors like this: stage2: --autofix proof-of-concept by andrewrk · Pull Request #12803 · ziglang/zig · GitHub
It wasn’t added to the language (yet?), but zls basically does the same thing.
1 Like
If you absolutely have to have a var that you do not mutate at the moment, there is an officially blessed (by the PR author) escape hatch:
var x: i32 = 0;
_ = &x; // makes compiler happy. `&` promotes x to l-value
2 Likes
This feature will be really annoying when you’re trying to isolate a bug by selectively commenting out sections of code. Imho, it’s more pragmatic to show the notices of this sort only when compiling for release. That’s usually when programmers have time to fix such issues.
5 Likes
Again there is an escape hatch _ = &x; that makes compiler happy and can be used while debugging.
2 Likes
When I’m compiling for debug, I’m already telling the compiler that the code isn’t finished. Why do I have to continually shush it?
9 Likes
I can see how it makes sense to have the compiler strict and leave it up to tooling to make experiments and refactors more pleasant. However, I would also prefer this to be a warning that could be ignored in debug builds but a compiler error in release (same for unused var).
5 Likes
So here’s a thought - why can’t these things be automatically promoted to const by the compiler?
There’s precedent for this behavior already in the compiler - it promotes types to pointers under specific optimization conditions (which has side effects).
Is anyone aware of a reason that this can’t be done implicitly when we already have implicit promotions via optimization levels? I don’t see this as being less clear than changing a value to a reference.
(also, welcome to the forum @fooblaz)
Though I do agree you should not be able to ignore warnings in production; I could see this and also unused var existing to a very specific class of Debug Warning. The current behavior could remain unchanged. For debug builds only flag --IgnoreDebugWarnings would still emit the warning but the compile could succeed. Anyway, I expect this sort of thing was already discussed at length around the subject of autofix etc…
2 Likes
I also wholeheartedly agree that compiler warnings have their place in tooling and am not just a little off put by the apparent inability to accept this and instead workaround this by moving the problem into IDE tooling. I’d also posit that there may be other types of warnings (think: linting) that may be impossible to fix in automated rewrites in the IDE, yet people find value in these diagnostics while not letting them break the build.
2 Likes
It’s too easy to fall into the “more is better” mindset. Sometimes less is better. Consider the scenario where the compiler issues no warnings regarding minor coding issues (those does not affect the correctness of execution) when building for debug but fails hard when building for release. Now programmers would have no option but to test in release mode prior to committing their work, lest minor issues like a unused variable cause an embarrassing fail at CI.
5 Likes
I see this objection repeatedly, but, as far as I know, nobody is advocating for making these checks “default off”.
What people are advocating for is a flag that only works in concert with debug build that lets people turn these off. That is strictly an “opt-in” froim the programmer, themselves. If you don’t turn off your debug-only flags and then get smacked in release, that’s your own fault.
One other problem has been that you quite often have to clear off all of these dumbass “errors” in order to get at real errors. I have had a couple of times where had I been able to get to the real error the dumbass “error” would have gone away.
6 Likes
Have you considered that it’s not necessarily about your code, but about other people’s code?
Consider: you want to compile and use a program, but it only builds in -O Debug and with --sloppy. As somebody who is only interested in using this application are you going to go through the code, fixing unused variables / constants and not mutated variables? Or are you going to say “screw it” and just build the thing as is?
I don’t think I would be willing to apply fixes just to have to do it again on the next update.
3 Likes
I would just not use external code that is written like that.
I see this example as similar to saying “if the compiler forces you to have tests in your code, except for debug / sloppy mode, what would you do with third-party code that does not have tests, and only compiles in debug / sloppy mode?”
In this (made up) example, I would say that I would not accept using such code in my projects, but I would also say that it is not the compiler’s business to enforce that code should always include tests.
7 Likes
Best argument so far here.
What if that really is the best course for the company at that particular moment? What if a company needs to ship a product by a hard date or they’ll go bankrupt, but devs can’t get a product out the door on time because they wasted too much time changing vars to conts, in code that didn’t even make to the final product? It’s one thing to incentivize good practices, it’s another to patronize your users, who you have no idea what their situation is.
6 Likes
I made an account just to comment on this issue.
Why not just give people the freedom to do what they want? Why force them to write proper code even if they want a sloppier one for whatever reason.
Like Gonzo pointed out before, there are cases where I know something’s bad, yet I want to be able to write code like that for whatever reason.
I don’t want to fix up an outdated repo with sloppily-made variables that I downloaded from somewhere when I just want to see how the compiled program works.
Again, let people write the code they want to if they understand the risk. The flag option that’s off by default is the best solution here and a perfectly viable compromise.
8 Likes
For context, here’s the original issue opened by Andrew:
A lot of the issues and arguments in this thread were discussed in the issue comments.
5 Likes