Given how capable our editors are today, it seems reasonable to both require semicolons at the end of statements and expect users to configure their editor/formatter to insert these semicolons for them wherever possible. The inability of the editor/formatter to automatically infer the locations of semicolons would be tantamount to a syntax error.
Certainly in enjoy Prettier (in spite of its foibles) for JS because of this sort of stuff. It removes whole classes of lint errors and adds semi-colons and doesn't care how I format the code as I wrote it.
Far too much thought and angst goes into things that should not need to be a concern. I used to feel more dubious about such tools, but after gofmt I tried Prettier and always use it now.
It's just one more bit of cognitive load that is gone. Indeed, if it doesn't reformat my code as expected I know I've made an error, so it's even quicker for me at noticing some bugs than ESLint messages which are already pretty excellent these days.
I agree. I have autoformatting turned on for everything and I just don't care what my code looks like because it’s consistent and I can get used to it.
I used to spend time configuring formatting settings to be exactly right, but nowadays I’m moving towards defaults.
My only problem with gofmt is that since Go standardized on tabs, I’ve encountered problems with noisy commits because people rewrap comments, and the comments will wrap differently depending on the individual’s tab width setting.
If your editor can do that, so could the compiler.
So, why require them? The only reason I can think of would be readability, but I haven’t seen a language where that is a serious concern (scala gets close with its “there must be a blank line here” at times)
I think “no semicolons” nowadays is the option to go for.
Editors can get away with things compilers can't- they are inherently interactive. If your editor gets it wrong, you can just fix it. If your compiler gets it wrong, you might get an error message, or weird behavior.
This is, for example, a major philosophy behind Rust's well-regarded error messages. The compiler rarely makes this kind of choice behind your back- instead, in reports an error message with a suggested fix-up for what it thinks you mean (and editor integration can apply those automatically).
Then the program source remains unambiguous and clear, there are fewer ways to confuse readers, but you still get all the benefits of "if your editor can do that, so could the compiler."
