<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=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 30.01.2016 um 20:26 schrieb Vanderlei Martinelli via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Radek, thank you for bringing this up, but I know the reasons they have been removed and I read the older messages (the `&&`, `||` and `!` operators mention was an intended hyperbole). I am aware of the “Swift evolution process".<div class=""><br class=""></div><div class="">And I still do not agree with the removal. You can consider code like:</div><div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">network.activiy++</font></div><div class=""><font face="monospace, monospace" class="">doSomeNetworkActiviy()</font></div><div class=""><font face="monospace, monospace" class="">network.activiy—-</font></div></div></div></blockquote><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">`activity` here does not need to be a numeric variable, but other thing. Does not make sense to write...</div><div class=""><br class=""></div><div class=""><div class=""><font face="monospace, monospace" class="">network.activiy += 1</font></div><div class=""><font face="monospace, monospace" class="">doSomeNetworkActiviy()</font></div><div class=""><font face="monospace, monospace" class="">network.activiy -= 1</font></div></div><div class=""><br class=""></div><div class="">...since I cannot add or subtract more than 1 in any case.</div><div class=""><br class=""></div><div class="">Now we can use methods like `increment` or `decrement`, but the two words, when reading, are similar and not clear as `++` and `—`.</div></div></div></blockquote><div><br class=""></div><div>For something like this I’d rather encapsulate this pattern of incrementing while an activity happens to ensure that the activity count is really decremented thereafter, i.e. something like the following (insert some better name for the method)</div><div><br class=""></div><div><font face="Menlo" class="">extension Network {</font></div><div><font face="Menlo" class=""><br class=""></font></div><div><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func incrementActivityCountWhile(@noescape action: Void -> Void) {</font></div><div><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>self.activity += 1 // or increment()</font></div><div><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>defer { self.activity -= 1 } // or decrement()</font></div><div><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>action()</font></div><div><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</font></div><div><font face="Menlo" class="">}</font></div><div><br class=""></div><div>which can then be used like follows:</div><div><br class=""></div><div><font face="Menlo" class="">network.incrementActivityCountWhile {</font></div><div><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>doSomeNetworkActivity()</font></div><div><font face="Menlo" class="">}</font></div><div class=""><br class=""></div><div class="">The point being that incrementing and decrementing are only written once (and the method probably being unit tested) and therefore the risk of errors creeping in is close to zero.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">OK, but my initial message intent is to prevent operator like `?:`, `??` and others to go away too (and maybe bring back the `++` and `--` operators, who knows?).</div></div></div></blockquote><div><br class=""></div><div>I agree with you there with regards to keeping these operators (and just dropping the prefix version and making the postfix version void would indeed have been a nice solution for ++ and -- but I didn’t object in the review, so that ship has sailed and I don’t think it’s a big problem; there are more important things to be done).</div><div><br class=""></div><div>Actually I didn’t have the impression that many people wanted to drop `??`. Actually I got just the opposite impression.</div><div><br class=""></div><div>-Thorsten</div><div class=""><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Best,</div><div class="">-Van</div><div class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jan 30, 2016 at 5:05 PM, Radosław Pietruszewski <span dir="ltr" class=""><<a href="mailto:radexpl@gmail.com" target="_blank" class="">radexpl@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" 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" target="_blank" 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 class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On 30 Jan 2016, at 19:12, Vanderlei Martinelli via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><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></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></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>