I disagree with almost all of the justifications, but I don't use Swift and mostly program in C++ so I'm pretty biased. > These operators increase the burden t

I disagree with almost all of the justifications, but I don't use Swift and mostly program in C++ so I'm pretty biased. > These operators increase the burden to learn Swift as a first programming language - Same could be said about almost any other slightly "advanced" feature. Not to mention the fact that I fail to see the difficulty here. Increment/decrement take literally a few minutes to explain and understand. Actually, it's more difficult to explain the concept of a function call, so let' propose to remove functions instead and stick with goto and global variables because they are easy to explain to a novice. > Their expressive advantage is minimal - x++ is not much shorter than x += 1. Increment/decrement looks visually more compact. (x += 1) looks hideous, has this "magic constant" and has 3 extra chars. Not to mention, x++ does have the expressive advantage, because it has entirely different semantics: "return value THEN increment", while x += 1 doesn't return anything in Swift (which is mentioned right in the next entry). > 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. It is not if you actually understand the semantics of those operators. Writing things like "return currentSize++;" is perfectly clear (assuming you know the meaning of the operator) and more concise and less noisy compared to something like "currentSize += 1; return currentSize;". > 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. By that logic, again, function calls should be banned. foo(bar(a), baz(b)) where bar and baz have side effects is also undesirable. > 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. I don't see how this is relevant at all. There are lots of operations that are only applicable to certain types. It doesn't mean such operations should be removed. You can't compute the sine of a matrix or a complex number yet you wouldn't remove sin(). You can't compare two complex numbers or two matrices but I don't see operators < and > going anywhere. > 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. True, but when it does become necessary I'd rather have that functionality available. I see no need to handicap the language this way. > Having to support these could add complexity to the potential revised numerics model. This might be the only valid (and the real) reason for removal... but I don't have enough information to comment on this.