[swift-evolution] Reconsider ++ and -- operators removal and prevent other well-known operators from change
devteam.codafi at gmail.com
Sat Jan 30 17:12:33 CST 2016
The readability arguments for ++ and — make no sense to me given that it is much more obvious, refactorable, and declarative to use
x = x.successor()
x = x.predecessor()
in their place. ++ and -- outside of loops are a code smell, and even within loops can easily be mistaken for one another or misused. As others have no doubt pointed out, if you want them back then define the operators yourself. Otherwise, I can’t say I’ve mourned the loss of these things enough to consider their reintroduction.
> On Jan 30, 2016, at 1:12 PM, Vanderlei Martinelli via swift-evolution <swift-evolution at swift.org> wrote:
> Hello everybody.
> I see Swift as a member of “C family" (a granddaughter/grandson of C, a daughter/son of Objective-C). OK, she/he is different and has her/his own personality like a daughter/son should be and have, but I still like to see Swift and recognize some traces that I know are things that became from C.
> This said, I would like to say that after the removal of `++` and `--` my code becomes less readable and more prone to errors. There were two characters to differentiate an addition from a subtraction, now there is only one (`+= 1`, `-= 1`). Also the character keys are very close in the US keyboard so it is easier to make a mistake and is not as simple as the previous solution when I typed two times the same key. Using Erica's way of saying certain things: I do not love the removal of `++` and `--`.
> I do not know how far the Swift is to the adolescence, but it is certain that teenagers are rebels. There's something very good at it. In most cases they are to be certain. But in some things they regret later. Now I see that many of us want to replace the `??` operator to something else. I'm wondering the next steps... To replace the `&&`, `||` and `!` operator with `and`, `or`, `not`? I’m not "loving" this as well.
> Are these changes really necessary for the Swift evolution? Is it the better path to deny its origin and to try to fix what is not broken? I would like you to think about it.
> There are many other things that really need to be improved and repaired and other things needed to are created. Those mentioned here in this message does not seem to fit it.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution