> On 7 Apr 2016, at 08:20, Vladimir.S via swift-evolution
> <[email protected]> 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 ;)
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
