<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Vanderlei,</div><div class=""><br class=""></div><div class="">The ++/— operators weren’t removed just because they are redundant with `+= 1`.</div><div class=""><br class=""></div><div class="">++ is a bit special in that it doesn’t just modify the receiver, it also returns the modified variable. What’s more, there’s this subtle difference between `++foo` and `foo++` when you pass it further along. And that, that difference, makes such use dangerous, and prone to bugs.</div><div class=""><br class=""></div><div class="">It’s also a useful feature — if you live in the world of C. But in Swift, where explicit increments and decrements are far less common, it was deemed that the slight utility and convenience of it does not justify the cost of potential confusion and bugs that arise from that.</div><div class=""><br class=""></div><div class="">Give the actual proposal a read: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md</a> — it does a pretty good job at explaining the disadvantages of ++ and —. It’s not just a stylistic choice.</div><div class=""><br class=""></div><div class="">And &&, ||, !, are not in danger. Browse this mailing list’s history — it’s been proposed more than once and immediately rejected as a change that really isn’t justified in any way.</div><div class=""><br class=""></div><div class="">Also, let me quote Doug Gregor from the core team:</div><div class=""><div class=""></div><br class=""><blockquote type="cite" class=""><div class="">We certainly don’t want open-ended rehashing of past decisions, and I’d like to have the baseline rule be something very close to “the core team’s decisions are final” both to prevent such rehashing and also to emphasize the seriousness of the public review process: the public review <i class="">is</i> the point at which we need to gather widespread feedback on the direction of the language. Determining that there is a problem “after we shipped it” is a failure of the evolution process.</div><div class=""><br class=""></div><div class="">The evolution process has a number of stages (idea/proposal draft/public review/core team), where each new stage brings additional scrutiny of the proposal. The hope is that this scrutiny is enough to prevent us from making poor decisions that may need to be overturned, and that the swift-evolution community is representative enough of the larger Swift community to provide that scrutiny. SE-0003 is somewhat special because it’s one of a few changes for Swift 3 that were decided prior to open-sourcing Swift: it didn’t go through the whole evolution process, so it didn’t have as many eyes on it as language changes do now.</div><div class=""><br class=""></div><div class="">So, overall, I’d say that the core team’s decisions should be considered effectively final. If something gets through the entire evolution process and then we later find out it was a bad decision—e.g., due to massive negative feedback when it reaches the wider Swift community or unforeseen difficulties in implementation/rollout/etc.—the core team could bring up the idea of backing out the change. However, the evolution process *should* prevent this.</div></blockquote></div><div class=""><br class=""></div>Best,<br class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 30 Jan 2016, at 19:12, Vanderlei Martinelli via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class="">Hello everybody.</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class="">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.</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class="">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 `--`.</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class="">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.</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class="">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.</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class="">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.</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class="">Regards,</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Helvetica;" class="">-Van</div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>