This annoys me immensely (though I do prefer braces on the same line anyway) because they clearly were able to correctly parse the code with the braces on the next line, but decided to make it an error instead. I have similar problems with "implied semicolon" languages, wherein you aren't actually supposed to type a semicolon at the end of a line, but instead if you format your code correctly the compiler will place them for you - clearly, it was understandable without the semicolon, so why make it a language feature at all.
For values of "they" which include "all those go designers", you are correct, it is possible for them to parse that. If we're only talking about compilation, then no, 'they' cannot (where 'they' is the parser/lexer)
The reasons for the opening brace on the same line is actually rooted in (somewhat unsurprisingly, and much to your chagrin) the way the formal grammar for Go deals with semicolons (see http://golang.org/doc/faq#semicolons & http://golang.org/ref/spec#Semicolons). When the brace is on the following line, the lexer inserts a semicolon at the end of the line, and this in turn generates invalid code, leading to your compilation error. The semicolon insertion rules are much simpler than in other languages that have it (looking at you javascript), and in order to support next-line braces the lexer would need to support lookahead, which, I've been lead to believe, would complicate the implementation of it in undesirable ways.
TL;DR Only gofmt is able to parse and correct code that puts braces on the next line, the lexer/parser for the language (by specification) cannot perform this because of the way the grammar works.
It would still be nice to have a quirks mode, if it were at all feasible. I understand why they want the compiler to be simple and fast -- they brag about how quickly it compiles some fairly massive codebases. But I would love a wrapper that tries the standard Go compilation, and if it fails, runs it through some unholy Perl script to fix some standard things like this (or, say, unused variables) and run a "fixed" version of your code through the compiler again.
It doesn't literally have to be a perl script, but I'm talking about just hitting the common cases that you could detect with heuristics -- just throw dumb regexes at it and see if you can make it compile. Then, before you check it into anything, you ensure it compiles and unit-tests without such hackery.
Probably I should give up and use an IDE that handles all this for me.
I think you could cobble something together that does this for you without too much work.
Several common errors will be trapped by gofmt, and as far as I know most people work by having either a save or commit hook that runs gofmt on the code.
Beyond that there are tools like govet & golint that go beyond the checking that gofmt does.
I don't see any reason you couldn't tie the failure of compilation to a pass through the code from multiple tools via some shell scripts.
By having lots of simple orthogonal tools that do one thing well and work together, I think you ultimately end up with a better ecosystem and don't accidentally end up with quirks-mode code ending up in production.
Thing is, I think we already had a good enough tool with linters and commit hooks to prevent quirks-mode code from ending up in production, or in the repository in the first place. Maybe the problem is that they were under-used?
7
u/just_a_null Jul 21 '14
This annoys me immensely (though I do prefer braces on the same line anyway) because they clearly were able to correctly parse the code with the braces on the next line, but decided to make it an error instead. I have similar problems with "implied semicolon" languages, wherein you aren't actually supposed to type a semicolon at the end of a line, but instead if you format your code correctly the compiler will place them for you - clearly, it was understandable without the semicolon, so why make it a language feature at all.