> Comparisons which will always evaluate to true or false and logical expressions (||, &&, ??) which either always short-circuit or never short-circuit are both likely indications of programmer error.
I regularly do things like:
if (0 && expression) ...
and:
if (1 || expression) ...
to temporarily disable a conditional when I'm looking for a bug.
Well, then presumably it would be nice to have your linter point that out for you so that you don't commit it to the codebase on accident! I've definitely seen a few of those kinds of things accidentally left in in production, which is definitely a code smell
WalterBright is the mantainer of the D language, so I guess he sees everithing from the point of view of the compiler.
I wrote a lot of code for the optimization step of the compiler of Racket, in particular steps to eliminate similar code. I saw those expressions and I inmediately think:
Macro expansions create a lot of similar expressions, and also more complex expressions that the compiler can reduce to trivialy looking expressions [1]. It's nice that the compiler can detect them and eliminate them, but raisng an error would break a lot of code.
My guess is that all three of us agree that the post is about linters, but it would be very bad to extend this rule to the compiler.
[1] For example, after an expansion of a macro or inlining a function you may get:
(define x (random 10))
(if (integer? x)
(display x)
(error "The number should be an integer"))
Despite being Turing complete[0], TypeScript itself is more like a linter with a special syntax than a complete programming language.
Its compiler can only transpile TypeScript into JavaScript code, and the language itself does not affect runtime behavior (with the exception of enums).
I regularly do things like:
and: to temporarily disable a conditional when I'm looking for a bug.