I don’t get all the hate these get. Why don’t they want to just remove the prefix forms and have the postfix forms return Void? I didn’t see much of an explanation.
Nothing’s “so bad” about it. ++ isn’t a big win, but it’s a very common operation and slightly easier to read, slightly easier to write, and slightly harder to screw up than +=. It’s a minor ergonomic improvement.
Combined with C-style return-from-assignment, pre- and postfix operators and the associated different semantics, and undefined behavior if you carelessly throw them around, it is overall a potential big mess (though it is very rarely used so poorly in practice); get rid of all that (e.g. by having assignment operators not return a value), and you’re left with a minor ergonomic improvement.
On balance I would prefer having it, but I certainly don’t think it’s reasonable to strongly oppose it; personally, I suspect people associate the concept of an increment/decrement operator with the mess of C semantics, but I have no strong basis for that suspicion.
Nothing’s “so bad” about it. ++ isn’t a big win, but it’s a very common operation and slightly easier to read, slightly easier to write, and slightly harder to screw up than +=. It’s a minor ergonomic improvement.
They probably should not be common operators, though. In a language with a good collection library that abstracts iteration away, I don’t think I ever use ++.
I actually like these operators. The major problem seems to always be confusion over the difference between prefix and postfix and what happens when you mix them (in short: just don’t), so I would go with the “assignment operators don’t return values” solution (which also fixes a wide variety of other problems, like if (x = 0)). I don’t see the issue with x++ and ++x being redundant, since x += 1 and x = x + 1 (and, by an immediate consequence of Turing completeness, an infinite number of other equivalent constructs) are already redundant and nobody every seems to be annoyed by +=.
Making them return void would make me feel significantly better about them. You haven’t explained why you like them - is it that they are visually more appealing than using +=, or is there another reason?
In my experience, somewhere between a large minority and a majority of uses of += are for incrementing. ++ is slightly easier to type and slightly easier to read, and prevents misinterpretation while skimming (e.g. x += 7 or x += l, though these are certainly edge cases). It’s a very small win, obviously, but—other than the hairiness introduced by trying to copy the C semantics in all their convoluted, occasionally-undefined glory—in my opinion still a win.
Thank goodness. If these operators hadn’t been in C originally and were being proposed for the first time for Swift (or any other language), what would the reception be?
People would go hog wild about what I brilliant idea it would be.
(Well, it depends. If it was proposed for Swift the reception would be as mentioned above, if it was for a language that has fallen out of grace it would be put down as a stupid idea.)
I don’t get all the hate these get. Why don’t they want to just remove the prefix forms and have the postfix forms return Void? I didn’t see much of an explanation.
why provide special syntax for increment by one? what’s so bad about
x += 1?Nothing’s “so bad” about it.
++isn’t a big win, but it’s a very common operation and slightly easier to read, slightly easier to write, and slightly harder to screw up than+=. It’s a minor ergonomic improvement.Combined with C-style return-from-assignment, pre- and postfix operators and the associated different semantics, and undefined behavior if you carelessly throw them around, it is overall a potential big mess (though it is very rarely used so poorly in practice); get rid of all that (e.g. by having assignment operators not return a value), and you’re left with a minor ergonomic improvement.
On balance I would prefer having it, but I certainly don’t think it’s reasonable to strongly oppose it; personally, I suspect people associate the concept of an increment/decrement operator with the mess of C semantics, but I have no strong basis for that suspicion.
They probably should not be common operators, though. In a language with a good collection library that abstracts iteration away, I don’t think I ever use
++.I actually like these operators. The major problem seems to always be confusion over the difference between prefix and postfix and what happens when you mix them (in short: just don’t), so I would go with the “assignment operators don’t return values” solution (which also fixes a wide variety of other problems, like
if (x = 0)). I don’t see the issue withx++and++xbeing redundant, sincex += 1andx = x + 1(and, by an immediate consequence of Turing completeness, an infinite number of other equivalent constructs) are already redundant and nobody every seems to be annoyed by+=.I propose full reverse: no + or +=.
:)
This makes me uncomfortable.
Making them return void would make me feel significantly better about them. You haven’t explained why you like them - is it that they are visually more appealing than using
+=, or is there another reason?In my experience, somewhere between a large minority and a majority of uses of
+=are for incrementing.++is slightly easier to type and slightly easier to read, and prevents misinterpretation while skimming (e.g.x += 7orx += l, though these are certainly edge cases). It’s a very small win, obviously, but—other than the hairiness introduced by trying to copy the C semantics in all their convoluted, occasionally-undefined glory—in my opinion still a win.Hmm, okay. That’s an argument I’m fairly sympathetic to, since I consider the loss to be fairly small as well. :)
Ha! Nice to see! Recent related thread. These are a small “convenience” that I’ve wanted to see the end of for a long time. :)
Thank goodness. If these operators hadn’t been in C originally and were being proposed for the first time for Swift (or any other language), what would the reception be?
People would go hog wild about what I brilliant idea it would be.
(Well, it depends. If it was proposed for Swift the reception would be as mentioned above, if it was for a language that has fallen out of grace it would be put down as a stupid idea.)
Yay! Not a swift fanboy, but this was the right decision.
The last reason given is the best: Would you add these operators to a language that didn’t have them? No? Then they are only baggage.