3 ms·

I 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. y

by pornel 4y ago

I 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 ago
I'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 ago
  I 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 ago
    Needing the warnings is still a failure of language design. Not being able to think of a better way isn't an excuse!

by pornel 4y ago

WalterBright 4y ago

I'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 ago
I 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 ago
  Needing the warnings is still a failure of language design. Not being able to think of a better way isn't an excuse!