14 ms·
The warnings problem is nicely solved in Rust: • There's a built-in way to silence specific warnings for specific portions of the code. When the compiler is wr
by pornel 4y ago
The warnings problem is nicely solved in Rust:
• There's a built-in way to silence specific warnings for specific portions of the code. When the compiler is wrong, instead of obfuscating the code to hide it from the compiler, you can directly mark "I know what I'm doing". Standard C can't do it, and compiler-specific #pragmas are much more clunky.
• Builds of dependencies automatically suppress lints, so builds with a -Werror equivalent won't break on someone else's code (that you may not be able to fix), just because your compiler has added new lints.
- WalterBright 4y agoThis kind of thing has been proposed many times over the years. It even existed back in the 1980s. I don't care much for it because it balkanizes the language into mulitple sub-languages.
- pornel 4y agoI don't see what is there to balkanize. Are you against any lints that aren't formally specified or may have false positives? If the compiler warns that e.g. you have an unused function argument, it may be a mistake, or it may be intentional (e.g. it's a callback for something that passes the arg anyway). Then you either have ad-hoc syntax extensions or dummy expressions for convincing the compiler it's used, which may fail in another compiler that defines "used" differently, or you explicitly silence the warning. Unused is relatively easy, but there's a whole category of pedantic lints for other code smells.
- WalterBright 4y agoI've resisted adding warnings to D for a long time. A couple have crept in, due to strong desire from the D community. A warning is a strong symptom of the language designer(s) being unable to decide what the language rules should be. So they make multiple languages based on switches. That's what balkanization is. D is a better language for having only a small number of warnings. It'd be even better with zero!
- pornel 4y agoI don't think it's possible to have a language so perfect that nobody can write bad/weird code in it. There are always going to be cases of code that is technically permissible, but very unlikely to be intended, and warrant a "did you really mean to do this?" lint. e.g. `unsigned < 0` is likely a mistake, but maybe comes from a macro/generic code that allows multiple types, or the zero is from some configurable constant. I don't see how flagging this is balkanizing anything. If the compiler doesn't flag code smells, it's a missed opportunity to help users and catch mistakes early. OTOH if the compiler turns potentially-benign things and unidiomatic code into hard errors, then it's annoying during development and refactorings. golang tried the no-warnings approach, and IMHO it's not working well. Sometimes it's too pedantic, but sometimes not strict enough. It sprouted `errcheck` and `go vet` to bring the warnings back.
- WalterBright 4y agoNeeding the warnings is still a failure of language design. Not being able to think of a better way isn't an excuse!