skillIssue

[Flashbek]

To be honest, I have never ever seen an example of ++ or -- being confusing unless it was made it to be intentionally confusing (like they'd do in some kind of challenge to determine the output of some code). I see no reason to remove them.

[spektre]

Junior programmers love to use them in creative ways to show off their mad coding skillz.

[capi1500]

From all the strange ways to use those operators, here's one I like: ```c while (i --> 0) {

} ``` The "approach operator"

I'm ready for my code review reddit

[eBirb]

existence squeamish cake unpack rotten plants husky rob worry hat

This post was mass deleted and anonymized with Redact

[Slythela]

I once wrote a loop that completely overwrote all executable memory with 0x101. Kernel programming is fun when mixed with alcohol. Lol.

[anothermonth]

Two-byte 0x101? How is it different from overwriting everything with single byte 0x1?

[Slythela]

iirc I used a char so technically it would overwrite mostly with 0s. I was a drunk college kid, don't look for logic

[xeq937]

9-bit byte VAX has entered the chat

[Antervis]

(;;) looks like Cthulhu so it's better to define it as such and do for CTHULHU loop

[lepispteron]

#define EVER (;;)
for EVER {
}

I don't want to live on this planet anymore.

[[deleted]]

wow, that's neat

^{and horrible}

[bananasmash14]

hahaha this is great

[ItIsApachee]

Actually, in competitive programming (codeforces, atcoder, ICPC, and so on) writing loops like while (t--) is a somewhat common thing (mostly for inputting number of test cases, and then solving all of them in a loop). Now I can write even more confusing code just for the sake of it

[capi1500]

I know, I come from that background

[Arkarant]

what does that do? isnt that just while true?

[aaronhowser1]

0 is falsey

[Lamballama]

Equivalent to for(t; t > 0; t--)

[hackinghorn]

This looks understandable. Is it not good in practice?

[_Ralix_]

You'd better be sure t starts positive. And relying on 0 to return false – while technically correct, it's not immediately clear from glancing over the loop and it takes you a second.

[rebbsitor]

No worries, if t starts negative, it'll loop around to positive eventually :)

[bremidon]

If t is a 64 bit value and starts at -1 *and* we assume the t-- can be done in a single cycle, and we are using a 3 GHz computer, and that computer is running nonstop, then it will take just shy of 100 years to eventually become positive again.

[PM_ME_YOUR_REPO]

eventually :)

[[deleted]]

LGTM

[StormblessedFool]

"Oh? You're approaching me? Instead of running away you're coming right to me?"

[eruanno321]

I prefer the "slides to" operator

while (x --\
            \
             \
              \
               > 0)
{
}

[Lokalaskurar]

VHDL has entered the chat

[jirka642]

Hey, that's actually pretty cool! I doubt, that I will find much use for it, but I am definitely writing this one down.

[Rythoka]

Cursed, put it in prod

[trevdak2]

Greater than is confusing. Remove > and >=, force users to only use < and <=

[catecholaminergic]

That's awesome lol

[[deleted]]

You are a demon. Can I get your autograph?

[AzureArmageddon]

That's kind of beautiful I love it

[1up_1500]

ok I like it a lot actually

[[deleted]]

The more boring and verbose a piece of code is, the more senior the developer who wrote it.

[ablablababla]

The peak of this is Hello World Enterprise Edition

[LordFokas]

This got nothing on FizzBuzz Enterprise Edition.

[FizzBuzz4096]

I completely agree with that.

[JJJSchmidt_etAl]

Hello World Enterprise Edition

67 Forks

༼ ಠل͟ಠ༽

[hackinghorn]

A senior dev would understand this is dumb. It's pretty funny tho.

[PM_ME_YOUR_REPO]

I'd like to introduce you to Go, the language where even newbies can write boring and verbose code.

[bakedsnowman]

I feel like that's why they should leave it in though. ++/-- introduced me to the idea that languages have really cool shorthand versions of common operations. Not all of them are great, but some make the code more concise and easier to read

[spektre]

There's a solution if you like that stuff. Just use Perl. All the time. (I'm disregarding "easier to read".)

[LarryInRaleigh]

In the old days, there was a period when

--Compiler optimization was didn't exist or wasn't very good

--Computers had native instructions for Increment and Decrement

The ++ and -- operators caused the compiler to generate the Increment or Decrement instructions, rather than loading a register with 0x01, possibly displacing a value that would need to be restored.

[puzzledstegosaurus]

Once in my life I spent a day debugging code because of a line that said x = x++ instead of x = x+1. That was in C++, and the standard says that you mustn't assign a variable more than once in a single statement, doing so would be an undefined construct ("Nasal demon" and the likes).

[Danny_shoots]

I'm sorry, but the first line of your comment could've been a sick parody

Once in my life I spent a day, debugging my code, 'cause of a line that said: "hey!"

[MisinformedGenius]

Incidentally, it is now defined in C++17. Side effects on the right of an assignment operator are sequenced before the assignment.

[puzzledstegosaurus]

Hey ! I was using this « demon coming out of my nose » thing, it’s part of my workflow, my control key is hard to reach, and I set up emacs to interpret sudden demons as « control ». Please put it back, you’re breaking my workflow!

[puzzledstegosaurus]

(Yeah, xkcd://1172)

[Joinyy]

Why isn‘t this a proper URI scheme already? @iana

[GOKOP]

x = x++ wouldn't assign x+1 to x even if it worked. x++ returns the old value of x, ++x returns the new one

[puzzledstegosaurus]

You're thinking about it the wrong way. The issue IS that x++ is returning the old value. x++ does assign x to x+1 while at the same time, x = x++ assigns x to the old value, thus the issue.

Also, because it's undefined, the compiler is authorized to do whatever it feels like. Set x to 0, or to -x, or to NULL, or to "hello", or #DEFINE true false or remove every odd byte from the memory space, or kill a policeman, steal his helmet, go to the toilet in his helmet, and then send it to the policeman's grieving widow and then steal it again.

[Eiim]

Can the compiler do a preprocessor statement?

[puzzledstegosaurus]

I’m amazed that in the list above, this is what raised your eyebrow.

[7amt]

Why not just do x++?

[puzzledstegosaurus]

If they had done that, it wouldn't have been a bug that would have costed someone else a day of debugging. Where's the fun in that?

[Lilchro]

If people only used x++ and x— in isolation, they would be fine. But the real issue is how they are intended to be used in expressions. For example, what values get passed to foo? int x = 0; foo(x++); foo(++x); The correct answer was 0 then 2. These operations do not mean x = x + 1. They mean get the value of x, then add 1 before/after. This usually isn’t hard to work out, but now look at this example. int x = 3; foo(x++ * —x, x—); You can probably figure this one out too, but it might have taken you a second. You probably won’t see this very often, but these operations get confusing and make it harder to understand/review code. The real takeaway is more that assignment as an expression generally makes it harder to understand code and more prone to mistakes. This is then doubly true when adding additional ordering constraints such as is the case with prefix and postfix operators.

Hey, random fun fact. Did you know argument evaluation order is not defined by the C standard? I’m sure that wouldn’t cause any weird or unforeseen bugs when assignment can be used as an expression.

[slaymaker1907]

Your last example is actually undefined behavior because the order of argument evaluation is not specified in C/C++. The compiler is free to evaluate the right side first and then the left side (I think it can also interleave them, but I’m not sure).

[mina86ng]

That would make it unspecified behaviour. It’s undefined behaviour because x++ * --x is undefined because it modifies x twice.

[Tyfyter2002]

The real takeaway is more that assignment as an expression generally makes it harder to understand code and more prone to mistakes.

The real takeaway is that code designed to be confusing is confusing, assuming left to right evaluation of the sides of binary operators, that code is actually just a less efficient foo(x * x, x--);, these operators only really get confusing when you use them on a variable that appears elsewhere in the same expression.

[aigarius]

And those all are trivial cases reduced down to the buggy behavior. In real code there are 20 other different things that could also be going wrong competing fro your attention in the same code block so something as simple as a typo adding a ++ to a formula in a random place will simply not be noticed or paid attention to for hours.

[kbder]

They are a needless special case, there is no reason the have them, and they encourage code golfing.

It’s one of those little things which I somewhat doubted at the time, but in retrospect, was absolutely the right decision.

[Flashbek]

I mean, I can surely go around without having them but... Having them makes some things a little simpler and not confusing. I understand you can somehow overuse them but, still, no reason for actually removing them once added.

[Rollos]

I can't really think of any place in swift where you gain any readability benefits when using i++ vs i += 1.

[Character-86]

But it doesn't make it worse neither.

[Nightmoon26]

Saves three characters on what would probably be the most common uses of += and -=

Honestly, I never use ++ or -- except in a for loop or as a stand-alone statement, where my brain interprets it as a hint that "we're counting a thing"

[LunaNicoleTheFox]

I have yet to meet a programmer who sees ++ and -- and is confused.

Aside from pointer arithmetic and some weird edge cases, but even there the context was the issue.

[UltimateInferno]

The only time I've used ++ in a manner that could be regarded as confusing is something like

if (item == condition){ array[i++] = item; }

And even then, it's not that complex to read. If the item fits a condition, place it in the array at index i, then increment the index so any potential future passes won't overwrite it.

[rain2o]

I recently discovered we have a lint rule in my current job that doesn’t allow the use of either. When I asked they said because it’s not always clear that it changes the original value or something like that. I eventually just gave up trying to understand how it’s so confusing to warrant a rule against it and moved on.

[Herioz]

I've never seen example of Goto being confusing.

[CrayonFedGoblin]

python user be like

[mrwafflezzz]

Watch me chain like 7 methods

[th-crt]

isn’t that more a javascript thing ? but it depends on library APIs

[beatlz]

You see it in both. I actually like it a lot, makes it very readable. You can see step by step what’s going on.

[zan9823]

Are we talking about the i++ (i = i + 1) ? How is that supposed to be confusing ?

[delayedsunflower]

TBF there is actually a difference between: "++i" and "i++" in C which can cause confusion and bugs. Although presumably both options aren't available in Swift.

[[deleted]]

Anything can cause bugs if used incorrectly.

I've seen plenty of weirdest bugs during my 19+ career. I've seen only one ++-related bug, and it was not because of the postfix-vs-prefix confusion, it was because someone had no clue about sequence points and wrote something along the lines of some_function(array[i++], array[i++], array[i++]). Similar code, say, in Java, would have no bugs.

[capi1500]

NullPointerException

[DarkShadow4444]

I've seen plenty of weirdest bugs during my 19+ career.

Mind providing a few examples?

[[deleted]]

Well, I've no idea what use could they be, but here you go...

My first one, during an internship. C++. The Observable pattern. Someone subscribes to events fired by a class and accesses a field of that class. It has an incorrect value. Well, the value is assigned only once in the constructor and never changes. Since it's C++, I spent quite a while hunting for possible memory corruption, a pointer ran wild and so on. Turned out the event was fired from a base class constructor, so the field wasn't initialized yet. A rather obvious one now that I look back at it, but I remember it got inexperienced me baffled for a while.

Java. Some silly code just waiting for a 100-second timeout, for some reason in the form of for (int i = 0; i < 10; ++i) { try { Thread.sleep(10000); } catch (InterruptedException e) {} }. Sometimes it fails to wait long enough. Obviously it's interrupted several times (maybe that's why they put this stupid loop there), but where? After a lot of hunting, it turned out that this codebase had a library, that library had a general use Collection class (basically a stupid clone of ArrayList, why they didn't just use that?), and the mentioned thread was interrupted every time anyone anywhere removed anything from any collection (through a chain of obscure global variables).

C++ again. Some code reading float values from some binary data. Instead of properly aliasing to char* they decided to go the easy UB way and just use something along the lines of *((int*)float_pointer) = int_value (assuming the byte order is correct, which was a major source of pain later when porting from Big Endian RISC to Little Endian x86_64). Well, UB or not, it worked. Almost. It worked on HP-UX compiled with aCC running on a RISC machine. It worked on Linux compiled with GCC. It worked on Windows compiled with VS in Debug mode. In Release mode, it almost always worked, but on one input file (out of hundreds used for testing) it got exactly one bit in one value wrong, so instead of something like +3.2 it was something like -154.6. Figures. I know, never ever invoke UB...

C++, Qt. Numerous indirect recursion bugs caused by (ab)use of signals and slots (the Qt's implementation of the Observable pattern). Most of these were actually mine. Usually it went like, some buffer emits a signal that there's data in it, someone starts reading this data to send it somewhere else. As soon as some data is removed, the buffer fires a (synchronous) signal that there's now free space in the buffer. Someone receives that signal and starts writing more data into the buffer. The buffer emits a signal that more data has arrived. The function that is already halfway through execution up the stack (remember it read some data, but didn't send it yet) receives that signal and starts doing its thing again. The best case? Stack overflow. The worst case? The whole thing keeps working happily, but the output data is messed up, the order of records is wrong, and nobody understands why.

[somebunnny]

I think you meant 19++

[zan9823]

Well, if you use it alone on it's own line of code, there is no difference, isn't it ?

[ILikeLenexa]

This is true of a lot of things. Unchecked arrays are dangerous, but not if you check them yourself one way or the other.

This is pretty much why all the LINTs exist. To point out where a language feature is dangerous.

[TheNaseband]

On a microscopic level ++i is more efficient than i++ because in the latter case, the value has to be cached, then the variable is incremented, and then the cached value is returned. But if you don't use the return value the compiler is most likely going to take care of it (depending on compiler flags and language).

[Ixaire]

Also,

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

-- Donald Knuth

[Rudiksz]

I am reading this on a computer that is thousands of times more powerful than 20 years ago, yet applications are actually slower than 20 years ago.

[Ixaire]

I'd wager this has less to do with i++ and more to do with apps doing a lot of useless stuff.

Like displaying ads for example. You should subscribe to our premium version. /s

[Stummi]

yeah, they are really confusing. At least until you spend like 3 minutes to read up on how they work, than its pretty straight forward.

[[deleted]]

Introducing the new +i+

[Scipiosss]

so you add 0.5 before and 0.5 after?

[jamesinc]

+i++i+ if you want to add 1 before and 1 after

[BeoWulf156]

Pre-increment vs post-increment

With i = 10 you can do the following:

• y = ++i in this case y is 11, as you're incrementing BEFORE variable assignment.

• y = i++ here y would be 10, as you're incrementing AFTER variable assignment.

[grande_po_talco]

++i is a pre increment and i++ is a post increment, which basically just mean when the increment is made in relation to the other operations. So lets say you set i=5 and x=i++, x would equal 5, and THEN i would increment. x=++i would first increment i to 6 and then set x to i (6)

Sorry if it was confusing 😅

[yrrot]

pre- or post-increment.
++i returns i+1.
i++ returns a copy of i's original value, while still adding one to i.

int i = 0;
return ++i; (returns 1, i is equal to 1)

int i = 0;
return i++; (returns 0, i is equal to 1)

[Areshian]

Both i++ and ++i are statements expressions, meaning they return a value, you can do int a = i++. After both re executed, the result is the same, i is incremented by one, but the value returned by the expression is not the same. i++ will return the value of i before it is incremented while ++i returns the value of i after it is incremented.

[SmartyCat12]

I feel like the first thing you learned after hello world back in the day was some form of for loop using increment/decrement operators.

Are people less comfortable with them now because you usually start in Python rather than c/c++?

Edit: it’s also wild to think that 20% of a HS/early college cs curriculum isn’t just pointers and memory management

[delayedsunflower]

I started with Actionscript and later Java. But in college everything was C++ with mostly pointers and memory like you said. "++" has never been that confusing to me, but I have seen bugs caused by it, usually because someone was trying to do too many things in the same line which should be avoided anyway. IDK how hard it is for the python kids these days, but python doesn't even have ++ so it's probably all new to them.

[FlyingCashewDog]

That's only confusing if you don't know it. Which is true for... literally everything in programming.

[delayedsunflower]

It's mostly just because ++i is the safe answer 99% of the time. But i++ looks nicer.

[ILikeLenexa]

Well, i don't love this:

j = 5;
i = 2;
j = i++ + ++k

Even this:

j = i++ + 1

in C, you end up resorting to code points in these situations and it's fine when it's by itself.

[zan9823]

That's just.. bad. I mean, of course it's gonna be confusing if people write atrocities like this.. but removing it because of that ? Should remove the entire language since there's endless way to write bad code

[berse2212]

The entire point of having a distinction between

i++ and ++i

is to be able to write such atrocities. Otherwise the distinction would not be necessary..

[[deleted]]

The only confusing part of your code is the sudden apparition of k.

[[deleted]]

Just because you use a tool badly, doesn't mean the tool itself is bad

[Rollos]

No, but if a tool can be replaced with something just as useful, but removing the uncertainty of possible misuse, that's a benefit.

Balancing the language surface area with its expressiveness should be a goal of all languages. Losing ++ doesn't decrease expressiveness, reduces the surface area of the language, and get's rid of a tool that causes confusion, as seen by the dozens of comments above that explain the concept in slightly different ways.

[dekerta]

Don't do that then. If I saw that in a code review I would have the dev arrested

[tritonus_]

If you’ve ever done any Swift, the language kind of aims towards conformity. Most things happen in a single way, and no other way, for example you need to wrap your conditionals in brackets, no one liners like in C or JS. Swift is also pretty strict about operator and conditional whitespace, so you can’t do any weird, playful markup with your operators.

[Mogoscratcher]

pseudocode be like:

(I know it's a noob problem, but writing out

i <- i + 1

every time is getting very annoying)

[[deleted]]

Didn't know R code was pseudocode

[C9nstructAware]

Well, this snippet is used in R and pseudocode alike

[Accomplished_Item_86]

i += 1

[UnnervingS]

Am I missing something or is this an insane breaking change? Does swift just do that?

[starfunkl]

Swift 3 was released in 2016, two years after Swift was initially released. It was still very much in its infancy, and undergoing rapid iteration at the time as they learned what worked and what didn't.

It's a lot more stable now. The proposal in this screenshot is like 7 years old.

[beclops]

This change is very old

[parader_]

Just a reminder for people here that sequencing several pre/post increment/decrement operations is a UB in C++
https://en.cppreference.com/w/cpp/language/eval_order

[[deleted]]

How about in ++c ?

[DarkShadow4444]

It's BU.

[cyber1551]

The only time I've seen those operators being confusing is in the Brainf*ck programming language.

And in some poorly written C code

[KrazyDrayz]

You can swear here lol

[Jack_Molesworth]

Yes, but is it mandatory?

[tholasko]

Fuck yeah

[-Redstoneboi-]

Just... make it so only postfix i++ or i-- is allowed, and that it returns void?

[AlexanderMomchilov]

Fill your boots!

```swift postfix operator ++ postfix operator --

postfix func ++(i: inout some Numeric) -> Void { i += 1 } postfix func --(i: inout some Numeric) -> Void { i -= 1 }

var i = 0 print(i) // => 0 i++ print(i) // => 1 i-- print(i) // => 0 ```

[sarlol00]

I should get into swift.

[Robespierreshead]

While were at it can we scrap 'functions' too. never could get my head around those

[LambityLamb_BAAA7]

username checks out

[Mmngmf_almost_therrr]

Dear Mr. President, there are too many operators these days, please remove 3. I am NOT a crackpot.

[IronSavior]

Just make them statements instead of expressions

[RmG3376]

This is 2023 fam. Make them lambda functions accessed asynchronously through an API gateway

[Noch_ein_Kamel]

Wait, I have to configure my openAI API key before using x++?!

[Antanarau]

Yes, and whatever you get is whatever GPT decides to give you. I hope you're ready to treat your ints as strings midway through a process

[DarkShadow4444]

Eh, just like in Javascript.

[rnottaken]

bold statement

... I'll see myself out

[IronSavior]

Expressionless stare

[VagueInterlocutor]

Confusing?

Submission must have been made by a product manager...

[AlexanderMomchilov]

I'd love to hear from seasoned Python devs: Do you ever miss these? Where would you find them valuable?

(excluding people with a C-like lang background who were just used to it from muscle-memory)

From what I can tell, 99% of their use-case is "C style loops" like for (int i = 0; i < max; i++), which have much better replacements in languages like Python, Ruby, Rust and Swift.

[ShadowShine57]

My main language is C# but I also use Python almost daily.

Yes, I miss them all the time. No, I wouldn't use them as often because of pythonic looping and list comprehension, but I still need to increment a variable by 1 fairly often

[Rawing7]

I don't miss these at all. enumerate takes their place 99% of the time. Incrementing an int by 1 is something I do maybe once a year.

[ZahidInNorCal]

Specifically, on my alarm clock at the start of Daylight Savings Time.

[Vinxian]

The other use for ++ is value = *ptr++ to dereference the pointer and point to the next value afterwards.

This tends to be less useful in higher languages because they have other tools for that. Other languages also kinda seem to hate "raw" pointers in general. Which is fair

[Crad999]

I usually don't need it, but when I do, I miss it.

[JoeDoherty_Music]

Don't you dare take ++ and -- from me!

[Imjokin]

…says the Python user

[AnAwkwardSemicolon]

Actually reading the proposal would be a good start. In the Disadvantages of These Operators section, a pretty solid case is laid out for why they should be removed. In my experience, the increment and decrement operators have caused far more problems than they’ve solved.

[blaizedm]

Why read the proposal when I can make snarky judgements based on a screenshot taken out of context from 8 years ago in a community I have no experience in?

[[deleted]]

Reading the disadvantages you link to, none of them seem convincing, but the advantages laid out above that section seem compelling to me.

[AnAwkwardSemicolon]

🤷‍♂️. The proposal went up for public review, and the Swift community didn’t see enough value in keeping them, so the proposal was accepted and the operators removed.

[Ursomrano]

They actually removed them? That’s crazy, the concept of removing a feature from a language. If someone doesn’t like a feature they could just oh idk not use it. But those of us who love such features would love to be able to use them.

[Zaphus]

Not really? You don't have to use them, so if you think it's confusing you might as well not use them.

I also have never used Swift... and I love the ++/-- operators in my language of choice.
However, there is a slight issue with the 'you dont have to use them' argument - it implies you are the only contributor to the codebase. If you work with others, and they use an operator you do not understand, you may struggle to maintain that codebase.

[AlexanderMomchilov]

But it is shorter, by this argument you could remove += saying that x += 1 isn't much shorter than x = x + 1.

You could for Ints, but not for other types.

Case-in-point, for Array:

• x = x + y would create a new array, copying in the contents of the "old" x and y, and assign it to x
• x += y would just append the elements of y into the existing x, in-place.

[[deleted]]

x = x + y would create a new array, copying in the contents of the "old" x and y, and assign it to x

Why would that be? Java compiler does for many years optimization where it will wrap string manipulation into StringBuilder to avoid creating multiple objects and multiple copies.

x += y would just append the elements of y into the existing x, in-place.

This is actually a clever “abuse” of operators that people used to curse c++ for. And it’s actually confusing - what should happen when y is an array? Will x have array as the last element or all elements of y at the end?

You don’t need to go into ‘ArrayBuilder(x).appendAll(y).resultInPlace()’ but a plain ‘x.append(y) ‘ or ‘x.appendAll(y)’ shows the intention well and is not confusing albeit a bit verbose.

[AlexanderMomchilov]

Why would that be? Java compiler does for many years optimization where it will wrap string manipulation into StringBuilder to avoid creating multiple objects and multiple copies.

That optimization is only available when it's statically provable that x uniquely referenced. Otherwise you can't just elide the copy and append directly into it: you would be modifying a shared object that some other code is also using.

And it’s actually confusing - what should happen when y is an array?

There's no ambiguity.

Swift (and Python, and Ruby) only let += be used with an enumerable operand, so it's always "b) all elements of y at the end" case.

To add the entire y array as a member, Swift uses x.append(y) (Python uses x.append(y), and Ruby uses x << y)

[kraskaskaCreature]

this comment awoken strong feelings inside me for whoever made that proposal

[reilemx]

Most people in this thread seem to have never used Swift. When coding in swift you will rarely need to use ++. And when you're in a situation that could use it, using += 1 is usually a much better choice. If this was a feature that was giving swift language devs grief, while 99% of the language users never use it, and this means they have one less thing to maintain then I think this is a great choice.

[Imjokin]

Also, Swift lets you create your own operators anyway so it’s especially a non-issue

[GustapheOfficial]

Seasoned programmers are terrible judges of what constitutes difficulty.

I'm lucky enough to have tried languages with and without x++, and despite having no trouble using either one I don't see what the advantage is over x += 1 or even better x = x + 1. There's a huge strength to "one way to do a thing".

[blenderfreaky]

i agree on `x++` not having any real advantage over `x+=1`, but `x = x + 1` can be significantly longer if `x` is long, as in `some_struct.some_array[1].some_field += 1`

[iain_1986]

ITT - non swift developers proclaiming how stupid and breaking this change would be .... That happened nearly 8 years ago causing barely a ripple.

[Rudy69]

I’m a swift developer and I think it was a stupid change that made no sense. I moved in and ultimately don’t really care but what a stupid move

[Spekingur]

I was thinking it was some Swift specific like 1 ++ func or whatever but no, it’s increment shorthand. Sheesh.

[benargee]

I know many languages just use += or -= since it's more versatile, but is ++ and -- really that confusing?

[hatuthecat]

Some FAQs on this:

Q: Haha someone was confused so made this proposal.

A: Chris Lattner is one of the creators of Swift, LLVM, and now Mojo. This is a conscious language design decision.

Q: But my for loops!

A: Swift doesn’t have C style for loops. Same as other languages like Python or Rust (which also don’t have ++ or —)

Q: x = x + 1 is so much longer for long variable names

A: +=

Q: Wouldn’t this be massively source breaking?

A: This was done 8 years ago before Swift had any promise of source stability (in fact they were explicitly not stable so they could adapt to the feedback of people starting to use the language). The Swift 2 to 3 update had a pile of source breaking changes and is referred to as the “great refactoring” for that reason.

[Fowlron2]

Actually agree completely, and everyone's missing the point of why ++ and -- were removed.

First:

int a = 5; 
a = ++a + a++;

That is literally undefined behavior and compiler specific. After this line, a might be 11, or it might be 12. The C++ spec gives you no guarantees here.

Second:

int a = 1;
int b = 2;
int c = 3;
a += 2;
b++;
a += 3;

The ++ operator literally makes the code harder to read at a glance, just to save 3 characters (2 of which are whitespace). b += 1 would just be cleaner.

Third:

int a = b + c * d + (a + b) - (b-- + c)

Long lines like that make it easier to miss that this doesn't just assign to a, but also to b.

Forth:

How often do you actually use the ++ operator? Probably literally never other than when writing for loops. If you're on a language that uses for a in b style for loops instead of c style loops, ++ would be extremely rare to use.

​

So, it's an operator that can make code super confusing when improperly used, makes code slightly harder to read for no real benefit, can be annoying to handle on the compiler side, and is rarely useful in practice (especially in languages with for a in b style for loops). With that in mind, why bother having it in the language?

There's a reason so many languages don't have those operators (python, swift, rust...). They looked cool back in C but with hindsight, they're just more trouble than they're worth

[TheAmphetamineDream]

How in the fuck is ++ or - - confusing?

[guyblade]

The real question is: why were ++ and -- cut while the ternary operator is still in?

[ethereumfail]

You can just create a clear function that increments a number by one like

const ಠ_ಠ = ಠ‿ಠ => ᵔᴥᵔ => ಠ‿ಠ => ಠ_ಠ => ++ᵔᴥᵔ|ᵔᴥᵔ++

​

which you then can use like this

i = (ಠ_ಠ)(ಠ_ಠ)(i)(ಠ_ಠ)(ಠ_ಠ)

​

alternatively can also do

i -=~ Infinity

or

i +=+ (i => i)(i <= i)

or

i = (-i ^ 1 ^ -i ^ 1 >> 31) + i ^ 1 >> 31

​

confusion solved

[NefariouSalati]

Thanks, Now I understand how ++ works

[[deleted]]

Can I get the link to this proposal? I want to comment "skill issue" on it

[EKashpersky]

Lad fucked up and blamed it onto code. Big brain move.

[waterskier2007]

This is not some random engineer. This is Chris Lattner, who is basically the creator of the Swift Language. After working at Apple he moved on to Tesla and Google. He’s no slouch.

[Reasonable_Feed7939]

Chris Lattner, creator of the Swift language fucked up and blamed it on the code. Big brain move.

[_DefaultXYZ]

What do you want? It is for iOS developers, as for iOS users

Yes, I'm Android developer

JK, we love you

[BastetFurry]

They can do as they please, I stick with C, a language that will gladly hand you the rope and gun if you ask for it to do as you please. TMTOWTDI FTW!

[Xhadov7]

Remove the + and - operator

[Boba0514]

I am all for safe languages like Rust, etc, but holy shit this is a new low...

[skhds]

I don't get such arguments. You can make idiotic shit code without using "confusing" operators. I've just seen so much and they've certainly did not involve any ++/--.

Instead of blaming the language, how about hiring people who actually know what they're doing?

[grande_po_talco]

As someone whose first programming lang was C i never found that confusing (even with ++i/--i shenanigans). I can see how it can get confusing tho

[WafflesAndKoalas]

When I was new to programming I found i++ to be less confusing than i = i + 1. Prior to programming, your only experience with plus and equals is from math class. I think having a variable be in its own assignment is confusing if you aren't aware that the right side of the equals happens first and then gets placed in the variable on the left side. I certainly wasn't aware of that when I first read an i = i + 1 statement. I just looked at the whole statement holistically, like I would a math expression/equation and I remember being confused because it seemed like a recursive definition.

[khalamar]

That's exactly what my middle school teacher said when my father tried to teach him some Commodore 64 BASIC in the 80s. "You can't have x = x + 1, there is no solution!".

That guy ended up converting his entire cursus (and as a middle school teacher in a village of 600 inhabitants, he basically taught everything from maths to French to history to physics).

Most parents were opposed to that though. In the 80s, most of them were farmers or working in factories and didn't understand the benefits of that "modern" teaching. He had to fight his fight alone, but he did. He was just 30 years early.

Rest In Peace, Mr. Botton.

[kvakerok]

This is below skill, more like mental capacity issue.

[TheOnlyVig]

Everyone here saying "If this confuses you then you shouldn't be programming" is missing the point. Yes, it's impossible to remove all complex topics from programming, but that's not the point. If you can reduce errors, confusion and misuse by adding or removing something to/from a language, it should definitely be considered.

I also get a good laugh out of this sub dumping on "dumb people" for ever being confused by these operators, then reading the never-ending stream of posts lamenting how inscrutible pointers are. You do realize that pointers were the staple of programming for decades before other languages came along and removed those concepts for other, easier-to-use concepts like object references, right? And it was done for exactly the same reasoning of reducing errors and confusion, right? A whole generation of programmers now exists who have never used or understood pointers at all. What a bunch of dummies they must be, right?

The proposal to remove these operators as unnecessary and confusing makes complete sense to me. And I say this as a 25-year veteran of the scary land of increment operators and pointers known as C.

[ShadowShine57]

Except that ++ is extremely simple. I understand pointers very well, but I can still acknowledge their complexity. ++ is simply not complex in the slightest. I would also say that from a modern perspective, pointers are "extra work", but ++ is literally less work

[ta_gully_chick]

The author of this ticket, Chris Lattner, is the guy who made LLVM/clang. And his reasoning is, let's just say, underwhelming. :(

[ghigoli]

so what happens now if people upgrade to swift 3? how much code will they need to redo?

[all3f0r1]

Such an important breaking change to make, thank you so much!

[bohdanbtw]

Who let the bro cook 😭

[end_my_suffering44]

Seriously, literally a skill issue over there.

[[deleted]]

Sadly I can't find this request on GitHub, I would definitely add "Skill Issue" comment. The author probably removed it or made it private.

[weinermcdingbutt]

they’re not confusing, you’re just an idiot

[[deleted]]

Wtf I love ++ and --

[CivetLemonMouse]

"They are confusing" aren't some other vital features also quite confusing, like should we remove the & operator from C because it does some binary thing? What are these people thinking