<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=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 7 Apr 2016, at 08:20, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><br class="">(TLDR: Suggest to change successor() method for Int values to follow default Swift rules for integer overflow. Probably some kind of successorWithOverflow could be introduced to use when needed)<br class=""></div></blockquote><div><br class=""></div><div>I’m a +1 for this; in fact, this is just how I assumed they worked, as the postcondition requirement for .successor() is that n.successor() > n if I remember right, which clearly can’t be the case if the limit of the integer is reached, so a runtime error seems reasonable.</div><br class=""><blockquote type="cite" class=""><div class="">(Btw, I personally totally disagree with the chosen solution regarding removing ++/--, I believe that we should leave ++ and -- as form of i += 1 code. I.e. only as assignment for variable, drop all other variants of using ++ and --.<br class="">And i += 1 is not just 1 char longer than i++ : in first case you have to press 4 different keys/combinations and just one(the same twice) in second case.<br class="">Just personal opinion :-) )</div></blockquote><br class=""></div><div>These were removed for a bunch of reasons:</div><div><ol class=""><li class="">Requiring the use of += 1 or -=1 is more consistent (assignment always includes an equals sign)</li><li class="">It can easily lead to confusing cases when used in function parameters or complex statements, making it unclear at a glance what a value will actually be. Some people argued that the operator should just have no return type to counter this.</li><li class="">If the operator had no return type to address #2 then it basically becomes redundant when i += 1 is identical, but also more flexible.</li><li class="">They were most commonly used within C-style for loops, which Swift no longer has.</li></ol><div class="">So I’m a -1 to anyone wanting those back ;)</div></div></body></html>