increment/decrement operators

[Terry Reedy]

On 12/5/2015 9:41 AM, D'Arcy J.M. Cain wrote:
> On Sat, 5 Dec 2015 13:56:47 +0100
> Robin Koch <robin.koch at t-online.de> wrote:
>> x += y works. (Well, it should.)
>
> It does, even on objects other than numbers.
>
>>>> x = "abc"
>>>> y = "def"
>>>> x += y
>>>> x
> 'abcdef'
>
>> x++ doesn't.
>
> No but it's just a special case of the above.
>
>>>> x = 1
>>>> x += 1
>>>> x
> 2

Apple is removing the ++ and -- pre- and post- increment and decrement 
operators from Swift 3.0 as redundant with += 1.
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md

The following section is a good summary of why they were never added to 
Python, and should not be.

'''
Disadvantages of These Operators

1. These operators increase the burden to learn Swift as a first 
programming language - or any other case where you don't already know 
these operators from a different language.

2. Their expressive advantage is minimal - x++ is not much shorter than 
x += 1.

3. Swift already deviates from C in that the =, += and other 
assignment-like operations returns Void (for a number of reasons). These 
operators are inconsistent with that model.

4. Swift has powerful features that eliminate many of the common reasons 
you'd use ++i in a C-style for loop in other languages, so these are 
relatively infrequently used in well-written Swift code. These features 
include the for-in loop, ranges, enumerate, map, etc.

5. Code that actually uses the result value of these operators is often 
confusing and subtle to a reader/maintainer of code. They encourage 
"overly tricky" code which may be cute, but difficult to understand.

6. While Swift has well defined order of evaluation, any code that 
depended on it (like foo(++a, a++)) would be undesirable even if it was 
well-defined.

7. These operators are applicable to relatively few types: integer and 
floating point scalars, and iterator-like concepts. They do not apply to 
complex numbers, matrices, etc.

8. Having to support these could add complexity to the potential revised 
numerics model.

Finally, these fail the metric of "if we didn't already have these, 
would we add them to Swift 3?"
'''

-- 
Terry Jan Reedy