Live data from Hacker News

Remove the ++ and –- operators

github.com

101–110 of 249 posts

Re: Remove the ++ and –- operators

#101

Earlier quoted context omitted.

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.

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.

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

Re: Remove the ++ and –- operators

#102

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

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.

Sorry, the lifetime winner of that award is JavaScript.

Re: Remove the ++ and –- operators

#103
post #91
post #69

Earlier quoted context omitted.

++ is a rare situation since the introduction of foreach. For example in the JVM checking for null would deserve an operator.

Would rather they started down the road of getting rid of null.

I was talking about the JVM. ;)

Re: Remove the ++ and –- operators

#104

"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?

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;

Now throw a few ++ and -- in there, and boy howdy.

Re: Remove the ++ and –- operators

#105

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

Then I take it you don't buy into the Python philosophy of "There should be one-- and preferably only one --obvious way to do it."

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

Re: Remove the ++ and –- operators

#106

Why remove x++ and not x += 1? Demand X = X + 1. For clarity/readability/formatting.

Well, I assume that it's because

  myObject.someVariable = myObject.someVariable + 1
is harder to read than

  myObject.someVariable += 1
Also it's annoying to type and increases the chance of typos.

Re: Remove the ++ and –- operators

#107
post #9

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

So.. get rid of 'x += 1' as well?

Yes! And local "var".

The optimizations that "var" allows should be the job of the compiler.

It's still needed at the non-local level on reference types, but could possibly be disallowed in structs as well.

Re: Remove the ++ and –- operators

#108
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.

Re: Remove the ++ and –- operators

#109

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 i…

Kotlin allows you to overload the += for your own classes. You just create a function called plusAssign such that a += b translates to a.plusAssign(b)

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

Post reply on HN