Go’s compromise here is that these operators are statements, not expressions. There is no return value. This makes it semantically identical to i += 1. It keeps some sugar while removing some classes of gotcha.
I could buy the argument if we were dealing with indexes or numbers where you had to read/hunt down occurrences of them to make sure they are what you expect. Like: make sure that a loop with a lot of indexes don't overincrement (out of bounds) or does something else that is wrong. But in this case the space isn't across a method, or a block. The space between the destination (i) and the increment number (1) is literally just 4 characters.
Of course you do, otherwise you wouldn't know it was an increment in the first place.
(No pun intended, but I also didn't edit it out...)
How often do your loops depend on incrementing a variable by one? In _Swift_ code.
Beginner here. Small detail...
`i++` is read as `i = i + 1` and not `i += 1`. A small, but important distinction, especially for a beginner. `i += 1` is also parsed as `i = i + 1`.
However for `i += n` it no longer parses as `i = i + 1` but rather `i = i + n` which is a step more difficult (and more powerful) than i++ which is always `i = i + 1`. However that is additional complexity not found in `i++`.
(This is why I found `i++` easier than `i += 1`)
main.go:6:2: should replace i += 1 with i++