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