
Remove the ++ and –- operators - Someone
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md
======
manaskarekar
> Their expressive advantage is minimal - x++ is not much shorter than x += 1

Personal opinion, but I definitely miss '++' every time I'm doing '+=' in
Python.

~~~
isomorphic
I think forcing me to use "+=" in Ruby reminds me that it's really a method
call (which can be overridden), rather than an increment operation on
primitive types.

~~~
odonnellryan
Yes, this exactly! While rarely a good idea, it does give you super powers
when dealing with specialized libraries, or when writing your own :)

~~~
paulddraper
Have you ever written a container (with an iterator)?

------
JoeAltmaier
Removing ++ et al: ok, they have their problems.

But retaining x += 1? That one has always annoyed me. Why does '+' (and
friends) get this special form, but not my functions? Just because they're
built-in.

They are useful; no argument there. Largely because 'x' can be a complex
reference, and you don't have to type it twice (and the compiler doesn't have
to figure out that its the same expression twice). E.g. x=x+1 is short but
_(rec_ )FnRec(iRec) = _(rec_ )FnRec(iRec) + 1; is not short. And the compiler
gets some great hints when the '+=' form is used (don't calculate the
reference twice).

I just want that for my stuff too! E.g. I may have a transformation method
Xform(Foo&, Bar) that returns another Foo&. I want to say foo = Xform(foo,
bar); but with 'foo' replaced by a complex reference. I have to say
FnFooRef(iFoo, "primary", red) = Xform(FnFooRef(iFoo, "primary", red), bar)

instead of FnFooRef(iFoo, "primary", red) Xform= bar;

I want my own 'operators' with the 'op=' syntax supported.

Probably its not terribly useful any more; languages support immutable data
and tuples and so much that don't work this way at all.

~~~
jsprogrammer
>Why does '+' (and friends) get this special form, but not my functions?

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?

~~~
JoeAltmaier
Huh. C++? You can overload operators, but define your own? I must have missed
something.

~~~
janvidar
Well, I suppose you can #define your own?

~~~
winter_blue
#define function(arg1, arg2, arg3) exists for creating macro functions, but
nothing exists for naturally creating macro unary or binary operators in C and
its descendants.

------
hoverbear
We don't have `++` and `--` in Rust either, and I really don't mind. The
amount of times I've went to do a `++` where a `+= 1` was clutter has been
perhaps one or two times.

Then again, my most common use for `++` was `for (;;) {}` index, and we have
better in these new languages like Rust and Swift.

There are millions of people in this world trying to learn to code and
understand the layers upon layers of cruft and quirks we've added. I don't
mind the `++` or `--` operators, but I certainly don't mind them being gone
either. They add extra complexity to code which is already arguably too
complex.

In any case, I favor understandability over guesswork, and `++` is another odd
cornercase which you have to mentally `grep` over.

~~~
marcosdumay
Oh, I've just closed a Haskell window, saw the title and thought "how would I
concatenate strings?", but I'm digressing...

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.

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

Wait, isn't this an undefined behavior? Is the order of evaluations of `x` in
the left side and `x++` in the right side defined? I'm always confused at
things like this!

~~~
marcosdumay
I dunno. I always thought the ++ operator was evaluated after the entire
statement, and every compiler that I could get my hands on behaved that way.

But, well, the specs are another matter entirely.

~~~
WorldMaker
Hah, just this sort of confusion is part of the proposal to drop ++ and --
from Swift.

x++ returns x and then increments it, so yes the spec agrees with your
intuition here.

Whereas ++x increments x and then returns the incremented x.

That subtle difference between x++ and ++x has been the debugging nightmare of
many a C developer over the years. It's also why there's a fun irony in the
C++ name and why people say the actual successor to C will be ++C.

~~~
marcosdumay
What?

I was talking about my statement at the upper comment. I used x++ there, not
++x. The doubt is about the value of the other x.

The difference you talk is about the main behavior of the operators. You won't
find any description of them that does not state it.

~~~
WorldMaker
Well, I made the wrong assumption in what was being asked then, I guess. I
would presume the "left to right" rule is more generally assumed knowledge in
C/C++ than postfix/prefix distinction of ++/\-- which are pretty much the only
unary operators with such a distinction in the language, whereas "left to
right" is a rather underlying general rule and one in which you generally
assume people are familiar with.

My apologies for answering the wrong question, but yes in that case the
standard is also mostly clear that you can assume that things are evaluated
from left to right in C/C++ and thus the first x in the line should be
evaluated prior to the x++ later in the line...

------
rocky1138
I've never understood the obsession with avoiding ++ and --. Douglas Crockford
advocates the same thing. All of the examples of why it's bad are contrived
and set up to fail. In the majority of real world instances, it's just us
incrementing or decrementing a single variable.

~~~
SamReidHughes
In Go, where they're a statement, they're fine. But as an expression, but
stuff can happen. In non-contrived, real-world, historical examples.

~~~
Gibbon1
Was just thinking in moldy old c code the two places to use ++ or -- was when
either incrementing pointers or indexes.

The other is ++ and -- also map directly to old school assembly language
instructions. Helpful when writing the back end of old school compilers.

Probably doesn't make much sense in a language with foreach() or dictionaries,
etc.

------
homulilly
I strongly disagree with this. Being able to do a very simple task like
increment or decrement a number inline is useful and reduces clutter and I've
always found the idea that the operator complicates things ridiculous. The way
they work has always been obvious to me since I first learned to program in
PHP as a tween.

~~~
ra1n85
"These operators increase the burden to learn Swift as a first programming
language"

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.

~~~
cballard
Apple has a long history of readability over terseness.

"plus plus" doesn't mean anything. It might even be confusing that it doesn't
add _2_.

~~~
dstanko
From Swift documentation:

for i in 0..<count { print("Person \\(i + 1) is called \\(names[i])") }

This ..< operator is so much more logical, of course! Not to mention == and
===. Logically, the first one compares twice and the second compares three
times (for luck), just in case first two comparisons didn't go through...

~~~
cballard
I would implement that like:

    
    
        zip(names, 1...names.count).forEach { name, index in
            print("Person \(index) is called \(name)")
        }
    

Or, in an ideal world:

    
    
        zip(names, 1...names.count)
            .map({ name, index in "Person \(index) is called \(name)" })
            .forEach(print)
    

Currently, that isn't valid Swift, "print" can't be used like that, though if
you define a closure it works:

    
    
        let printIt = { x in print(x) }
        
        zip(names, 1...names.count)
            .map({ name, index in "Person \(index) is called \(name)" })
            .forEach(printIt)
    

I think that Swift _could_ use = for equality, since assignments return Void
and comparison returns Bool. Maybe it should.

But your argument boils down to "if you can't be clear everywhere, don't be
clear anywhere". That's not a good goal.

~~~
dstanko
My argument ultimately "there are better things to do". At the same time,
interpreting ++ as add-add is certainly not an argument. You can say that you
don't like infix and postfix operators, but not whether they are readable.

If you consider readability, then why !a instead of not(a)? Why || instead of
or?

------
mwsherman
Go’s compromise here is that these operators are statements, not expressions.
There is no return value. This makes it semantically identical to i += 1. It
keeps some sugar while removing some classes of gotcha.

~~~
throwaway999888
Just having `i += 1` would seem more in line with Go's professed Simplicity
philosophy. When both `++i` and `i += 1` mean the same thing, you might as
well drop one of them. `++i` (and/or I guess `i++`) is barely syntactic sugar.

~~~
shurcooL
FWIW, Go linter suggestion is to to use i++ but i += 2. If you write i += 1,
it'll suggest you should write i++ instead:

    
    
        main.go:6:2: should replace i += 1 with i++
    

That said, if it were removed, I'd probably be happy because it makes the
language a little simpler, but I don't mind having it too much either, because
it's a statement rather than an expression.

~~~
asddubs
wow, now that seems needlessly confusing. "use x += _" to increase x by any
amount except one, in which case you use x++"

~~~
PeCaN
+= 1 is a pretty common case though, it doesn't seem particularly arbitrary
for it to be special. It's not "clean" or "minimal" but it is pretty
convenient.

------
dboreham
Good. I've always presumed ++ is in C because processors had an increment
instruction that was faster than add back then, and for the PDP-11's
autoincrement addressing mode. Presumably Dennis' compiler would have been
that much bigger in order to spot these optimizations vs having the programmer
explicitly invoke them -- perhaps big enough to no longer fit in memory.

~~~
mturmon
People suppose this, but that's not quite how it happened. C came from B, and
B had ++ also. But B came before the PDP-11. The PDP-7 had hardware that
supported auto-increment-by-one, and Ritchie suggests that's where ++ came
from.

The PDP-7 assembler manual is at [http://bitsavers.informatik.uni-
stuttgart.de/pdf/dec/pdp7/PD...](http://bitsavers.informatik.uni-
stuttgart.de/pdf/dec/pdp7/PDP-7_AsmMan.pdf), 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-...](http://bitsavers.informatik.uni-
stuttgart.de/pdf/dec/pdp7/F-75P_PDP7prelimUM_Dec64.pdf) . 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](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."

~~~
dboreham
Very interesting. I have supposed this since using PDP-11 assembler and
reading Dennis' compiler in the late 70's.

There were machines with auto increment modes long before the PDP-11 though,
e.g. "[http://ed-thelen.org/comp-hist/GE-635.html#Indirect](http://ed-
thelen.org/comp-hist/GE-635.html#Indirect) Then Tally (IT) Modification"

~~~
mturmon
I hear you. I learned assembler on the PDP-11 -- a delightful memory -- and
had the same misconception until I read Ritchie's piece.

------
mikeash
Note that if anyone truly misses these operators, you can add them back with a
few lines of code. Swift has extensive support for custom operators, and if ++
and -- disappear as built-in operators, you can just implement them as custom
operators.

I see a lot of people complaining that they like ++ and -- who may not realize
that they can still have it if they want it. I get that there are legitimate
questions over whether it's wise for the community and such, but for your own
work, you can still have it if you want it.

~~~
mei0Iesh
That's good. Can you make anything? Like x+ is x+=1, x++ is x+=2, x+++ is
x+=3? x+++++++++++++++++++++++++++++

~~~
mikeash
Yep:

[http://swiftstub.com/43404468](http://swiftstub.com/43404468)

Obviously you should be careful not to commit such atrocities in any code that
might ever see production.

------
ChrisLTD
_" Drop one of x++ or ++x. C++ programmers generally prefer the prefix forms,
but everyone else generally prefers the postfix forms. Dropping either one
would be a significant deviation from C."_

Funny given the name of the language.

~~~
warmwaffles
C++ is not even a good increment of C. Yes it had a lot of inspiration from C,
but in all seriousness, it should not have been called C++ since it is not
backwards compatible with C without some serious work. Honestly longest
running ironic language name.

~~~
richardwhiuk
Sorry, the lifetime winner of that award is JavaScript.

------
jheriko
post increment/decrement is definately worth removing imo.

so few people understand its behaviour and it enables some really revolting
and difficult to read things. i think a lot of people learned this in the 80s,
90s and 00s even... its not a new revelation.

the pre-increment/decrement though? i think having these is important. there
are plenty of contexts away from numbers where they make sense (things can be
ordered and not have a concept of addition)

~~~
alricb
What about a function named succ or next? They would make things a bit more
explicit, and succ has its own tradition.

~~~
cballard
Those exist, as part of "RandomAccessIndexType", to which "Int" conforms:

1.advancedBy(1) == 2

This is different than ++, though, because ++ mutates the value, and
advancedBy(:) returns a new one.

------
Alupis
Why not leave those operators for more "advanced" users?

I also contest "++" and "\--" operators are seriously tripping up "beginners".
In most programming books, it's taught a few chapters in...

~~~
cballard
Because non-advanced users will incorrectly abuse them. That's why ARC doesn't
let you call retain and release manually, even though there's no _technical_
reason it couldn't.

~~~
Alupis
> Because non-advanced users will incorrectly abuse them.

I don't see how this is a valid reason to remove the operators completely.
Beginners will get it wrong sometimes, so we should remove it?

Beginning users are likely to make all kinds of errors, so the implication
would be maybe we should remove the entire language...?

Not to mention, pre-decrement and post-decrement are not complicated concepts.
There are many valid reasons to use both, although post-increment/decrement
seems to be the more common use.

~~~
cballard
Well, the same argument can be made for pointers, which are clearly harmful to
a safe language.

Swift does include them, but puts a screaming "Unsafe" in front of their type
names so that it's clear that unless you really know what you're doing, you're
probably doing something wrong.

There's no way to do that with a ++ operator, so it's being removed.

~~~
davrosthedalek
Do really think the complexity of pre/post-in/decrement is on the same level
as pointers?

~~~
dragonwriter
I think the added complexity to added value ratio is worse for pre/post-
in/decrement operators than it is for pointers, even if the added complexity
is less.

~~~
cballard
Yes - or in the Apple ecosystem, method swizzling is incredibly useful but
also incredibly harmful - both to performance through necessitating dynamic
dispatch, and to confusion, because WTF, method swizzling?

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

And there is no ++ equivalent of x += 2.

~~~
cballard
Yes. Anointing "\+ 1" as a thing that needs special syntax is _weird_.

~~~
spc476
Not necessarily so if you come from a strong Assembly language background.
Most processors have a special instruction for incrementing a register that's
shorter (and faster) than the more generic ADD instruction.

For instance, on a 64-bit x86 machine,

    
    
        ADD RAX,1
    

is nine bytes long, while

    
    
        INC RAX
    

is one byte. Maybe not as much a win these days, but back when memory was
smaller and more expensive, it was worth it.

~~~
DiThi
Nowadays, a compiler that doesn't optimize a "+1" is a bad compiler.

~~~
spc476
These days yes. But when C was first being developed, when you _might_ have
had 64K of memory for everything? Back then it might have been a sane choice.

------
jhallenworld
The postfix versions of ++ and -- have no simple analogue. I propose fixing
this: z = (a += 1) means z gets the new value of a, but z = (a +: 1) means z
gets old value a, same as in z = a++.

Likewise, z = (a : 5), means that z gets old value of a, then a gets 5.

This makes for a nice family of operators. For example, to swap the contents
of two variables you can say: a:b:a (or a=b:a). Also you can rotate through a
bunch of variables: a:b:c:d:a transfers all the contents to the left, and puts
the old value of a into d.

The . operator should have an assignment form as well, so that you can say: p
.= next instead of p = p.next

Now you can traverse linked lists very concisely: for (p = first; p; p .=
next) serialize(p);

Of course .: will have the expected meaning: return old value of left side,
then replace it with one of its members. So you can say:

    
    
       while (p) serialize(p.:next)

~~~
SamReidHughes
Why do you want this?

~~~
jhallenworld
Same reason mathematicians have symbols like: ∀, ∃, ∴, ∬, etc.

In fact now that Unicode is universal we should use all of these operators too
:-)

------
Animats
I tend to agree with removal. Nobody writes

    
    
        for (i=0;i<n;i++) *a++ = *b++;
    

any more.

~~~
mFixman
All the cool kids use Null-terminated strings now.

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

------
personjerry
It really bothers me that the title should say "\--" but instead says "–-"
which consists of two distinct characters.

------
ninjakeyboard
scala has no ++ or -- operators. It's a-okay. Swift is shaping up to look a
lot like scala actually. The biggest problem with ++ and -- operators is that
they hide a side-effect in another unrelated operation. In a language that
supports more functional approaches at the outset, it makes sense to just omit
these operators I think.

------
jakejake
If there's some technical or performance reason for getting rid of this as far
as the swift compiler goes, then I guess whatever just tell me how to
increment a number and that's what I'll do.

But to try to say that x++ is complicated to understand? It's no more
complicated than a lot of operations. I don't think anyone would intuit what
x%2 means either. There are things that you can get just by looking at it, and
others that you just have to learn once, then you go "oh, that's what it does"
and move on.

------
ape4
Get rid of `x += 1` also. Its just shorthand for `x = x + 1`. /sarcasm

------
mikejmoffitt
"These operators increase the burden to learn Swift as a first programming
language"

Come on. There are legitimate reasons not to carry one language's expressions
to another, but this isn't a good one. Most people first learn of ++/\-- as
"By the way, you can use ++ as a shortcut to add one" and leave it at that.

~~~
JoeAltmaier
But its more complex than that- there are the prefix and postfix forms, which
both leave the base incremented but return a different value (before or after
the increment). That's the complexity that trips up novices.

------
logn
I had no idea there was even a debate about this let alone people passionate
about each side. This is bike shedding right?

~~~
RotsiserMho
Maybe. No one really wants to make a new C++ without being careful not to make
something as convoluted as C++.

------
mmillis1
I feel stupid for asking but is this really a topic of discussion? ++ and --
were one of the first things I learned when starting to program. Its simple
and quick to write.

Is this a thing some "new" programmers don't understand what is going on?

Am I taking crazy pills?

~~~
Retra
The first thing I learned when programming was GOTO and raw pointer handling.
Both are simple. Both are pretty stupid.

------
codeshaman
The ++ operator is one of the main features that brought me to C and C++ when
I was just a kid. Basic and Pascal didn't have it and it looked so cool ! Then
I had to learn the rest of the language which goes around the ++ operators,
but I'm not kidding ==> the ability to write code using ++ or -- was _the
shit_ back then.

To me, ++ is the signature operator of the C language AND the operator in the
title of the compiler that Swift is written in: C++

I guess it wasn't just me who liked it quite a bit ;).

After so many years I still see a bit of magic in this strange repetition of a
character..

So I think they should definitely stay, even if (because) it's not the most
pragmatic thing to do.

------
bootload
_" When the return value is needed, the Swift += operator cannot be used in-
line, since (unlike C) it returns Void."_

Why was this decision made?

~~~
legulere
So you can't do this:

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;

~~~
bootload
_" So you can't do this: a += b -= c; Don't ask me in which order it
executes,"_

thx for the reply @legulere, I can now see the void, why would the language
allow syntax that smells so bad? Can you do this in _" c"_?

------
seivan
Good, I always sticked to += 1 because it felt better. Weird to see I'm not
alone.

I could never really memorise the difference between i++ and ++i because it
just seemed like such an obscure thing to have. It's really really weird (and
cool) to see someone suggesting removing it.

------
bcoates
While I agree that having both pre- and post- versions is confusing overkill,
++ is no more sugar for x += 1 than x+x is sugar for x*2.

Increment is the fundamental operation, += is sugar for repeated
incrementation, not the other way around.

------
cballard
While 4 touches on this a bit, I think another reason is that mutable value
types are generally harmful. Save mutability for compiler optimizations and
write your code with "let".

~~~
oofabz
You need mutability to write for loops.

~~~
cballard
C-style for loops are discouraged in good Swift code. Use map, ranges, or
for/in instead.

------
imdsm
> Keep both x++ and ++x in the language, even though they do the same thing.

?

~~~
dragonwriter
> > Keep both x++ and ++x in the language, even though they do the same thing.

> ?

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.

~~~
imdsm
This a delayed response for which I apologise, but thank you for yours, this
makes complete sense now. I must have missed this at the time. Makes sense
now.

------
brandonmenc
I have rarely used ++ and -- outside of inc/decrementing pointers and loop
counters in C code. They probably won't be missed in Swift.

------
bphogan
One of the reasons they state is that ++ makes it harder for beginners.

I just taught ++ and -- to 1st semester students last week. There were no
problems.

~~~
mayoff
Time that could have been spent teaching them something else useful, if your
language didn't have ++ and --. Even if all features of your language are
easy, teaching/learning each feature takes time.

~~~
bphogan
My point was that it's a poor reason for removing it from a language.

Believe it or not the concept of

x = 5

is harder to understand.

They know that = means equality, because of algebra. I have to retrain prior
knowledge, and since humans rely on prior knowledge to learn new things
quickly, it's more difficult.

Having to explain == or .eq or, god forbid, === takes way more time to explain
than:

"x = 0". x++ adds 1 to x. So when you need to increment by one, you can do x =
x + 1, or you can do x++ which is a shorter way."

Boom. Done.

Not exactly a good reason for taking it out of a programming language. That's
all I was saying.

Do I care that Swift has it or not? Nope. But I just thought this particular
reason was silly.

------
scolfax
FTA:

Advantages: "The primary advantage of these operators is their expressive
capability"

Disadvantages: "Their expressive advantage is minimal"

------
nevereverreg
Why remove x++ and not x += 1?

Demand X = X + 1. For clarity/readability/formatting.

~~~
dragonwriter
> Why remove x++ and not x += 1?

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.

------
ozy123
much ado about nothing

------
nraynaud
I would just make a++ an instruction, and remove the rest.

------
wolfhammer
Why not noPlusPlusMathObject.addOne(referenceFor x)?

------
nice_byte
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.

~~~
jboy55
Its funny, I was just performing an evil whiteboard coding question.

My question involves a sorting function and thus thinking of a problem one
step at a time. Start with an inspection, then based on the element perform an
action, then marking some bounds with pointers to spots within array.

Since you're doing this one item at a time, you're __always just going to be
incrementing or decrementing once __.

Even if I do a

    
    
       for a in range(15): 
    

in python. Within that loop, I'm doing an action on _one_ item. If I'm
counting I'm most probably counting by 1.

We do things all the time in coding by looking at things one at a time, that's
why increment and decrement __by 1 __is so useful to me.

In this case, the candidate couldn't not understand how to increment a
"pointer" by one and wanted to solve it with a list. They still figured it
out, but it got me thinking of this and maybe we're moving away from really
thinking of things one step at a time. To me, its a very useful skill, and the
reason I ask the question.

------
deeteecee
lol.

------
mei0Iesh
Is this like the Apple idea to have a 1-button mouse? I like to ++ things,
because when I'm coding, it fits better with that focused efficient state of
mind where you don't have to think about x + 1, you just say ++ and it's
bigger. But I'm not an Apple programmer, so maybe this isn't for my style.

------
grabcocque
Doing stuff because that's the way C does it is a surefire route to
unintentional autoemasculation.

~~~
tizzdogg
Doing stuff because that's the way elisp does it is a surefire route to
unintentional autoemacsulation.

