3 ms·
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
by nightpool 3y ago
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 3y agoHaving them in a linter is fine, but in the compiler itself, maybe not.
- nightpool 3y agoWell, luckily this is a post about linters...? I'm not sure I understand your comment. How is it related to the article?
- gus_massa 3y agoWalterBright 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"))
- maxloh 3y agoDespite 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). [0]: https://github.com/microsoft/TypeScript/issues/14833 https://github.com/microsoft/TypeScript/issues/14833