& and << are both multiplicative operators and have the same binding strength. The suggestion implies a different binding for & than for <<. Where do we stop?

/cc: @rsc who wrote the code for the spacing around operators in go/printer.

The expression formatting logic is basically unchanged from day 1 of the public release, and I think we should leave it that way. There are any number of arguments for and against minor changes, but widespread agreement is more important than any single change. As Rob said recently, gofmt particular syntax choices are no one's favorite but gofmt is everyone's favorite.

For this specific case, a goal for the expression formatting was on a particular line, operators with spaces have looser precedence than operators without. If we write this expression as x&1 << 8 that implies something about & vs << that simply isn't true.

By itself, the expression formats as x & 1 << 8. When used inside a larger expression with another precedence, it gets compressed to make clear that the outer expression has different precedence:

x & 1 << 8
x&1<<8 == 0
x&1<<8 | 2   NOT  x&1 << 8 | 2

Note in the last case especially that a special case for & vs << would produce a confusing result with respect to addition-level operators like | or +.

No matter what the formatting is, people will still make the occasional mistake. It's actually working very well. Let's leave it as it is.

@minux What about making cmd/vet warn that "a&b<<c == 0" and "a&b<<c != 0" are probably missing parentheses? They seem very unlikely to occur legitimately.