For the first two caveats, I actually agree that we could and should handle ambiguous input. It just hasn't been a priority because doing that properly would be quite a bit of work, and such ambiguous syntax isn't particularly common. See https://github.com/mvdan/sh/issues/686 for my current thoughts on how to tackle it.
The third caveat concerns parsing `export` and `let` as keywords rather than as builtins. Like the README says, this is to properly build the syntax tree without leaving opaque strings as expressions, but also to support `declare foo=(bar)` which wouldn't work if `declare` was treated like any other builtin simple command.
How else would you have a static parser handle these two builtins? They are in a bit of an awkward middle ground between builtin and keyword. My instinct is that giving them special treatment in the parser to allow tokens like `(`, while at the same time representing them in the syntax tree with opaque strings as expressions, would be pretty underwhelming to any users of the parser.
That said, we already have that problem with `let "foo=123"` for example, where our parser currently represents the expression as the quoted string without going any deeper. https://github.com/mvdan/sh/issues/754#issuecomment-96329574... considers doing a second parse stage in the shell interpreter to fix cases like these, though always doing a second parse could get expensive.
We _could_ leave all arithmetic expressions as input strings in the parser, and do all the actual parsing when they are evaluated. That would be more compatible with Bash and more consistent. But it would also be less useful to any parser users who don't run into any of these weird edge cases, which aren't common at all, I think.
In short, I have some ideas, but I'm not sure at all what's best :) Doing a good job for 99% of users feels better than aiming for 100% compatibility with bash syntax, particularly where bash syntax is a bit weird.
You might be getting confused. gofmt does not warn about lacking comments, that was golint, which has since been deprecated.
gofmt does not divide or re-join imports into groups, but gofumpt does :)
Neither gofmt nor gofumpt enforce a character limit on lines. Some form of line length limit is the most common gofumpt feature request by far, but one that I haven't been brave enough to release in any form.
Perhaps read gofumpt's README, it has a lot more information.
I hadn't really considered that people might want to do this. From experience reading and writing Go code for ~8 years at multiple companies, the only times I've seen leading or trailing empty lines in blocks have always been either inconsistent or unintentional, and usually both.
Are there Go codebases that stick to the formatting you show, out of curiosity?
Either way, please file a bug. Perhaps others can chime in there if they also use the same style.
I've seen this once across many Go codebases, it was someone who even a year in writing Go still refused to consistently name constants and global variables without snake_case, among other similar behaviors.
Support for allowing configuration of such a thing would be a misfeature if I was to be asked.
gofumpt will never have formatting knobs, following gofmt's design. But if one of gofumpt's rules forbids a style which is reasonable even if it's not very popular, we might want to make the rule more conservative or remove it entirely.
It's not quite as simple as that :) I think upstreaming half of gofumpt's additions to gofmt would be reasonable, but the person who wrote and maintains gofmt is Robert Griesemer, who continues to be quite busy with generics. They are still actively fixing typechecking bugs and performance issues, as far as I can see.
I think it's hard for anyone to justify pausing or distracting the generics work in favor of upstreaming parts of gofumpt. At the end of the day, gofumpt works today - it's just a bit awkward to have it as a third party tool.
That said, it is on my radar to talk to him and make a plan for upstreaming.
Edit: to clarify what I mean with the above: I of course could do the legwork to port my formatting changes to go/printer, the guts of gofmt. The reason I mention Robert is that he'd be the one to consider and approve each formatting change, and review the code changes and tests. That work is trickier than it sounds, because you have to think about the possible effect any formatting change would have on all kinds of existing Go code out there.
For open source projects in general, and the Go project in particular, I think it is easy to underestimate how much maintainer time is consumed discussing & considering whether a change should be made.
I agree that empty lines can help. I've been careful to only remove empty lines which, in my opinion, don't help when structuring the code or making it more readable.
If you have examples where gofumpt is being a bit too aggressive, I'd like to hear about them. I've corrected, and even removed, some of gofumpt's rules in the past thanks to user input.
I use gofumpt for all my go code (have been for at least two years), and I use empty lines for structure. Out of the tens to hundreds of thousands lines written, I don’t recall a single instance where an intentional empty line was removed. I doubt gp’s comment is based on experience. Another giveaway is the “seems” at the very beginning.
I'm the author of that presentation, and I'm surprised to see the very similar content and structure, to say the least. I left a comment on the Reddit thread[0] to see if I'm missing something.
Thanks -- I replied in full there. I reused your title, which I can see was confusing. However, this is all my own writing and research, primarily from the official (draft) release notes, new linker design doc, golang-dev, and GitHub issues. But your slides were a minor source, so I still should have attributed them. That would have helped you and not hurt anyone -- sorry!
Simple Go binaries do tend to be statically linked, which is where I think the confusion comes from.
The most common source of dynamic linking is cgo, since CGO_ENABLED=1 is the default when not cross-compiling. For example, importing os/user will dynamically link against libc, unless you disable cgo or force statically linking with libc.
See https://github.com/golang/go/issues/26492 for more details. I think the purpose of the flag will be to force static linking in all edge cases, while not disabling cgo explicitly.
