[swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Haravikk]

> On 7 Apr 2016, at 08:20, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
> (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)

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.

> (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 --.
> 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.
> Just personal opinion :-) )

These were removed for a bunch of reasons:
Requiring the use of += 1 or -=1 is more consistent (assignment always includes an equals sign)
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.
If the operator had no return type to address #2 then it basically becomes redundant when i += 1 is identical, but also more flexible.
They were most commonly used within C-style for loops, which Swift no longer has.
So I’m a -1 to anyone wanting those back ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160407/2afea812/attachment.html>