Remove the ++ and –- operators (github.com)

https://www.python.org/dev/peps/pep-0020/

for others, though, it really enables the writing and reading of some very elegant and concise code.

They also make the tools that consume that language slightly more complex. It doesn't sound like much, but in aggregate it's the difference between writing a parser for Java vs. a parser for C++.

I remember the day I first saw a '++'. It was a rainy night, and I was inspecting a colleague's for loop, when suddenly a '++' operator appeared. I asked myself, "What in the holy bacon of Zeus is that?" So I looked it up in my book. My head almost exploded, and I asked myself if I should quit programming immediately. It was simply too complicated. After four months of agony and pain I finally recovered and started programming again. And yet... Sometimes, when it's raining outside, the memories come back. Programming... No, my life will never be the same again.

And simplicity is an actual goal of computer language design.

The PDP-7 assembler manual is at http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp7/PD..., but I can't see any reference to this auto-increment hardware, or to an assembler directive using it. What I'm getting at is that there appears not to have been an assembly language construct for auto-increment on the PDP-7 at all, even though its hardware supported it.

The hardware "auto-indexing" is described at page 3-12 of the PDP-7 architecture document, http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp7/F-... . It is enabled only for about 8 special memory addresses in each 8K of address space, so it is weird and handicapped by comparison with the PDP-11.

See Ritchie's history (http://www.bell-labs.com/usr/dmr/www/chist.html) --

"Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed.

"The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1."

It looks like they may be trying to make it easier for current tweens that would have otherwise learned PHP.

Don't see the value in this. These operators are terse, well known, and are implemented in a wide array of languages.

If readability matters then the rationale that x += 1 is more readable than x++ is very reasonable.

  I've always found the idea that the operator complicates things ridiculous

But no, not only for for(;;). There's also the too common array traversal:

while(something) a[x] = b[x++];

And lots and lots of ugly but useful uses in pointer arithmetics where they make things clear. They have no place in any other language, but I'd really miss both operators in C.

Your functions can get that (and other) special form. You need to use a language where you can define your own operators. Have you looked at C++, C#, Haskell, or LISP?

     x = <LHS> + 1;

     x =  (<LHS> + 1) / atan(<LHS>) - <LHS>;

  z <- copy(x)
  z += y

In Swift, + and += are just operators. They're two separate operators which happen to do similar things. In Swift, an operator can be defined to mutate its left-hand operand, which += is defined to do. You can create your own operators that do that as well.

If you want to do it for methods, Swift has mutating methods which can change the thing they're sent to. In this case, you'd mark your Xform func as "mutating" and then you can write someComplexThing.Xform(bar) and it will mutate someComplexThing in place.

Of course, if you want to support both forms, you end up with a bit of redundancy as you have to define stuff twice. But the built-in stuff is the same way, and you can at least define one in terms of the other to cut down on duplication.

https://kotlinlang.org/docs/reference/operator-overloading.h...

[0] http://doc.perl6.org/language/functions#Defining_Operators

Especially when doing straightforward data manipulations in R or Python, endless lines of `bla = map(bla, fn)` start to look crufty, so much so that Pandas in Python now allows you to add `inplace=True` to almost any data manipulation method to cut down on the verbosity. But then, sprinkling that keyword argument across every line isn't exactly better. Neither is endless chaining. Looks like we could still use some syntactic improvement.

    func += (inout left: Vector2D, right: Vector2D) {
        left = left + right
    }

I'm not saying this is a shining example of brilliant programming, but it is in a semi-working state and something "in a similar style" (that is, a three-pass tokenizer -> LR parser -> LR parser where scope information and other metadata is computed in the second pass and fed into the third) should be able to handle the changes you're talking about.

https://github.com/dbpokorny/autoclave/

    func +=(inout lhs: Int, rhs: Int)

You might object that special forms are still privileged, e.g. foo[idx]+=1. But in fact these are not special: one of the surprising features of Swift is that inouts work on computed properties. For example, say we add a mutable property highHalf on UInt64:

    extension UInt64 {
        var highHalf : UInt32 {
            get { return UInt32(self >> 32) }
            set { self = (self & 0xFFFFFFFF) | (UInt64(newValue) << 32) }
        }
    }

    var x = UInt64.max
    x.highHalf -= 1

Swift is the first language I've encountered that works this way; are there others?

You are right, take a look at Perl 6 infix operators. You can define your own operator(treat it like a function, as such) and then use it.

https://perl6advent.wordpress.com/2013/12/22/day-22-a-catalo...

The reason is that I don't want to see you escape your strings by writing

  input escapequotes= input

A key part of the reason for removing the ++/-- set of operators seems to be that they conflict with Swift's pattern of mutating operators returning void. (An alternative offered was revising them so that they followed that pattern.)

+=/-=, like simple assignment, do not have that problem.

  myObject.someVariable = myObject.someVariable + 1

  myObject.someVariable += 1

    while (*a++ = *b++);

a += b -= c;

Don't ask me in which order it executes, I would need to read the C standard again and wrap my head around how this case is described therein.

I'm also not sure wether this is defined or undefined behaviour:

a += b -= c *= a;

> ?

That was a subalternative underneath the alternative of changing the operators to return Void like other assignment operators. ++x and x++ differ in that the former returns the value after the increment, the latter the value before; if they return void, all they do is the increment with no difference.