4 ms·
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
by mwsherman 11y ago
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.
- throwaway999888 11y agoJust having `i += 1` would seem more in line with Go's professed Simplicity philosophy. When both `++i` and `i += 1` mean the same thing, you might as well drop one of them. `++i` (and/or I guess `i++`) is barely syntactic sugar.
- AnimalMuppet 11y agoi++ is different from i += 1 in this way: += could be i += 2 or i += j or something else. I have to pay attention to be sure. But i++ can only add one.
- throwaway999888 11y agoYes, you actually have to read the statement `i += 1` in order to know what it does. I don't see how that is an argument. It's barely longer than `i++`, in any case. 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.
- AnimalMuppet 11y agoBut the point is that with ++, I don't have to look at all at the increment - I know what it is. The issue isn't how far away I have to look, it's that I have to look at all. (Or I don't look, and just assume that it's an add-one because that's what it always is, and then wonder why my loop doesn't work right.)
- dragonwriter 11y ago> the point is that with ++, I don't have to look at all at the increment Of course you do, otherwise you wouldn't know it was an increment in the first place.
- AnimalMuppet 11y agoWell, all right, my brain has to parse one fewer symbols. ++ is the equivalent of parsing +=, but there's no "1" or "j" or anything else that I have to parse in addition. (No pun intended, but I also didn't edit it out...)
- throwaway999888 11y ago> (Or I don't look, and just assume that it's an add-one because that's what it always is, and then wonder why my loop doesn't work right.) How often do your loops depend on incrementing a variable by one? In _Swift_ code.
- Nadya 11y ago>Yes, you actually have to read the statement `i += 1` in order to know what it does. 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`)
- shurcooL 11y agoFWIW, Go linter suggestion is to to use i++ but i += 2. If you write i += 1, it'll suggest you should write i++ instead: main.go:6:2: should replace i += 1 with i++ That said, if it were removed, I'd probably be happy because it makes the language a little simpler, but I don't mind having it too much either, because it's a statement rather than an expression.
- asddubs 11y agowow, now that seems needlessly confusing. "use x += _" to increase x by any amount except one, in which case you use x++"
- PeCaN 11y ago+= 1 is a pretty common case though, it doesn't seem particularly arbitrary for it to be special. It's not "clean" or "minimal" but it is pretty convenient.
- mwsherman 11y agoAgree they could have done without it entirely.